---
title: "Grafana Alerting"
description: "Send Grafana Alerting notifications to Uptimeify Incident Management via a Webhook contact point, mapped from the alert group's first alert."
---

Uptimeify's Grafana preset maps Grafana Alerting's webhook contact-point payload directly: the alert name, severity label, status, and instance are pre-mapped from the first alert in the notification group.

## 1. Create the alert source in Uptimeify

Go to **Incident Management → Alert Sources → New**, pick the **Grafana** preset, name it, and create it. On the success screen, copy the ingest URL (`https://<your-domain>/api/im/ingest/<token>`). It is shown once and never displayed again in cleartext. If you lose it, rotate the token from the source's **Settings** tab.

## 2. Add a Webhook contact point in Grafana

1. In Grafana, go to **Alerting → Contact points** and click **Add contact point**.
2. Give it a name (for example `uptimeify`) and set **Integration** to **Webhook**.
3. Set the **URL** to the ingest URL you copied in step 1, and leave the **HTTP method** as `POST`.
4. Leave the payload as Grafana's default webhook body. Uptimeify's preset reads the standard fields (`alerts[]`, `status`, `commonLabels`, …) it already sends. Save the contact point.

## 3. Route alerts to the contact point

A contact point only receives notifications once a **notification policy** routes to it:

1. Go to **Alerting → Notification policies**.
2. Either point the **default policy** at your new contact point (every alert routes there), or add a nested policy with a label matcher (for example `severity =~ ".+"`) that routes matching alerts to it.
3. Save. Grafana now calls the webhook whenever an alert rule matching that policy fires or resolves.

## Default field mapping

Grafana groups alerts into one notification; the preset reads all of these from the **first alert** (`alerts[0]`) in that group, falling back to the group-level `title` for the title field:

| Grafana field | Normalized field |
|---|---|
| `alerts[0].labels.alertname` (falls back to the top-level `title`) | Title |
| `alerts[0].labels.severity` | Severity (via the map below) |
| `alerts[0].status` | Status: `resolved` resolves the alert, anything else (typically `firing`) keeps it open |
| `alerts[0].labels.instance` | Host |
| `alerts[0].fingerprint` | Dedup key: Grafana's own stable per-alert identity |

### Severity map

Grafana has no built-in `severity` label. This only works if your alert rules set one (for example via a `severity` label on the rule):

| Grafana `severity` label | Uptimeify severity |
|---|---|
| `critical` | `sev1` |
| `high` | `sev2` |
| `warning` | `sev3` |
| `info` | `sev4` |

If your alert rules don't set a `severity` label, every alert falls back to the source's configured default severity.

## Sample payload

This is the shape of payload Uptimeify's Grafana preset expects:

```json
{
  "receiver": "uptimeify-webhook",
  "status": "firing",
  "orgId": 1,
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "HighCPU", "severity": "critical", "instance": "server1:9090" },
      "annotations": { "summary": "CPU usage above 90% on server1" },
      "startsAt": "2026-07-17T12:00:00Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "https://grafana.example.com/alerting/grafana/abc123/view",
      "fingerprint": "8f3b1c9a2d4e5f60",
      "silenceURL": "https://grafana.example.com/alerting/silence/new",
      "dashboardURL": "https://grafana.example.com/d/abc123",
      "panelURL": "https://grafana.example.com/d/abc123?viewPanel=2"
    }
  ],
  "groupLabels": { "alertname": "HighCPU" },
  "commonLabels": { "alertname": "HighCPU", "severity": "critical" },
  "commonAnnotations": { "summary": "CPU usage above 90% on server1" },
  "externalURL": "https://grafana.example.com/",
  "version": "1",
  "groupKey": "{}/{alertname=\"HighCPU\"}",
  "truncatedAlerts": 0,
  "title": "[FIRING:1] HighCPU",
  "state": "alerting",
  "message": "CPU usage above 90% on server1"
}
```

You can send this exact payload against your source's mapping from the **Payload Mapping** tab in the dashboard to verify the setup before wiring up a real notification policy.