Skip to content
downpipes docs

Send downpipes alerts to Grafana IRM

Grafana IRM is Grafana’s incident and on-call product, and the current home for what used to be Grafana OnCall. The OnCall OSS project entered maintenance and was archived in 2026, so a new setup should target Grafana IRM. There is no dedicated Grafana channel here; you add a generic webhook channel and map downpipes’ event JSON to Grafana IRM’s fields with a documented recipe.

What you need

  • A Grafana IRM account where you can add a Formatted Webhook integration and copy its URL.
  • Access to the downpipes console with permission to configure notifications (Operator, Approver or Owner) to add and test the channel.

Set it up

  1. In Grafana IRM, add a Formatted Webhook integration and copy the URL it gives you.
  2. In the downpipes console, open Notifications, choose Add a channel and pick Webhook (generic HTTPS POST). Adding a channel needs permission to configure notifications, so an Operator, Approver or Owner can add one.
  3. Paste the Grafana URL into the HTTPS URL field. It must be https and carry no embedded credentials. Name the channel and save it, then a rule routes events to it.
  4. In Grafana IRM’s Formatted Webhook template, map downpipes’ downpipe-event-v1 body to Grafana’s fields: set alert_uid from dedupKey (before engine 0.3.6, from a stable field such as the downpipe id), and title and message from the detail. An account-level event has one key for each event name, so repeated alerts of one account-level event group onto one open alert, and no recovery closes it. Set state to ok when the body carries recovered: true, and to alerting in all other cases. Read the note below for engines before 0.3.6.
  5. Choose Test on the channel to confirm delivery without sending real alert content, then check the alert group appeared in Grafana IRM.

Good to know

  • alert_uid groups, and recovered gives you ok. Grafana IRM resolves an alert group when it receives a state of ok on the same alert_uid. From engine 0.3.6, the body carries dedupKey, which is the same on a trigger and on the recovery that clears it, so map alert_uid from dedupKey. A recovery also carries recovered: true, which is the field to map to ok. Do not derive ok from the event or the severity: a recovery reuses the same event name and the same severity as the trigger it clears, so a template keyed on those fields reads it as another firing. Before engine 0.3.6, the body has no recovered or dedupKey field, and only the detail wording tells a recovery from a trigger. The canary stream names its recovery in the event field as canary-recovered on every version. That event carries no recovered field, and its dedupKey is account:canary-recovered, not the key of the canary-dead alert. So this mapping does not close a canary-dead alert. Close it by hand. When you do not want to maintain a mapping, route to the PagerDuty, Jira Service Management / Opsgenie or ServiceNow channel alongside Grafana IRM: each of those sends a real resolve, close-by-alias or severity-0 clear on recovery with no mapping from you.
  • Confirm the current recipe in Grafana. The Formatted Webhook fields are Grafana’s to define and can change between versions, so check the field names in your Grafana IRM console rather than assuming them. downpipes’ side is just the downpipe-event-v1 JSON; the translation is yours.

Last updated .