Skip to content
downpipes docs

Send downpipes alerts to incident.io

incident.io takes alerts through a custom HTTP alert source. There is no dedicated incident.io channel here; you add a generic webhook channel pointed at the alert source, and map downpipes’ event JSON with incident.io’s transform.

What you need

  • An incident.io account where you can create a custom HTTP alert source and read its URL and token.
  • 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 incident.io, create a custom HTTP alert source and copy its URL and token.
  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 alert source URL into the HTTPS URL field. It must be https, carry no embedded credentials and not be a workers.dev host (validateChannel, engine/src/notify-routing.ts). Name the channel and save it, then a rule routes events to it.
  4. In incident.io, write the transform that maps downpipes’ downpipe-event-v1 body (the event name, severity, downpipe id and name, and a one-line detail) to the alert fields.
  5. Set the dedup key to a dot-pointer path at the dedupKey field, so repeated events for one downpipe and event land on the same alert. 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.
  6. Choose Test on the channel to confirm delivery without sending real alert content, then check the alert arrived in incident.io.

Good to know

  • Resolve on the recovered field. A recovery carries recovered: true and the same dedupKey as the trigger it clears, so set the transform’s status to resolved when recovered is true and to firing in all other cases. Do not key the status on event or severity. A recovery reuses the same event name and the same severity as the trigger: a cleared backup failure arrives as another backup-failure at critical, so a transform keyed on those fields reads it as another firing. The canary stream names its recovery in the event field as canary-recovered. 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 transform, route to the PagerDuty, Jira Service Management / Opsgenie or ServiceNow channel alongside incident.io: each of those sends a real resolve, close-by-alias or severity-0 clear on recovery with no mapping from you.
  • The webhook channel sends only the JSON body. downpipes posts the downpipe-event-v1 body to the URL and adds no auth header of its own, so give incident.io the token in a form its HTTP alert source accepts, and confirm the exact URL and token placement in the incident.io console rather than assuming it here.

Last updated .