---
title: "Alert Source Setup Guides"
description: "Step-by-step guides for wiring Zabbix, Datadog, Grafana Alerting, Prometheus Alertmanager, Sentry, or any custom webhook to Uptimeify Incident Management."
---

Each guide below walks through configuring one monitoring/alerting tool to send its alerts to an Uptimeify **alert source**: a per-tool ingest endpoint with a built-in field mapping, so alerts land in Incident Management already normalized (title, severity, status, host) without writing a custom integration.

## Guides

- [Zabbix](./zabbix)
- [Datadog](./datadog)
- [Grafana Alerting](./grafana-alerting)
- [Prometheus Alertmanager](./prometheus-alertmanager)
- [Sentry](./sentry)
- [Custom webhook](./custom-webhook)
- [Email](./email)

The **Email** guide works differently from the rest: an email source has no JSON webhook payload, so the "How ingestion works" and "Severity mapping" sections below (both webhook-specific) don't apply to it; see that guide directly.

## How ingestion works

1. In the Uptimeify dashboard, go to **Incident Management → Alert Sources → New** and pick the preset matching your tool. Give it a name and, optionally, assign it to a team.
2. Uptimeify generates a unique ingest URL:

   ```
   https://<your-domain>/api/im/ingest/<token>
   ```

   The `<token>` is shown **once**, immediately after the source is created. Copy it right away. It is never shown again in cleartext. If you lose it, open the source's **Settings** tab and rotate the token to get a fresh URL (also shown only once).

3. Configure your tool (see the tool-specific guide) to send an HTTP `POST` request with a JSON body to that URL whenever it fires or resolves an alert.
4. Uptimeify parses the payload using the preset's field mapping (or your own edited mapping, from the source's **Payload Mapping** tab) and queues it for asynchronous processing into Incident Management.

This is a different mechanism from the [Events Ingest](../events-ingest) endpoint (`POST /api/im/events`): that endpoint is authenticated with an organization-wide API token and has no preset field mapping (every request maps through a single auto-provisioned `api`-type source). The per-tool ingest URL above has no separate authentication (the token embedded in the URL **is** the credential, so treat the full URL like a password), but comes with a ready-made mapping for the tool you picked.

## Request limits

The same limits apply to every ingest URL, regardless of preset:

| Limit | Value | Failure |
|-------|-------|---------|
| Body size | 256 KB | `413 Payload Too Large` |
| JSON nesting depth | 20 levels | `422 Unprocessable Entity` (`payload_too_deep`) |
| Body must be valid JSON | — | `422 Unprocessable Entity` (`invalid_json`) |

An empty request body is treated as `{}`.

## Response

A successful request always returns `202 Accepted` immediately: the alert is queued, not yet processed:

```json
{ "accepted": true }
```

An unknown, wrong, or rotated-away token returns `404 Not Found` (`not_found`). Every kind of authentication failure returns this same response, by design. It never reveals whether a token used to exist. A `503 Service Unavailable` (`unavailable`) means the alert could not be queued and is safe to retry.

## Severity mapping

Every preset except **Custom webhook** (which has no severity selector) maps the vendor's raw severity value onto one of Uptimeify's four incident severities:

| Uptimeify severity | Meaning |
|---------------------|---------|
| `sev1` | Worst / critical |
| `sev2` | High |
| `sev3` | Warning |
| `sev4` | Low / informational |

A vendor severity value that isn't in the map, or a missing severity field, falls back to the alert source's own configured default severity, not automatically to `sev4`.