> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dash0 alert integration

> Send Dash0 check rule alert and recovery events to Flashduty On-call through a webhook notification channel.

Use a Dash0 webhook notification channel to send check rule alerts to Flashduty On-call. Each Dash0 issue identifier (the combination of a check rule and a resource) maps to one Flashduty alert. Trigger and recovery notifications for the same identifier continue updating that alert.

<div className="hide">
  ## In Flashduty On-call

  ***

  Create either a dedicated or shared **Dash0** alert integration and copy its complete Push URL.
</div>

## Configure Dash0

***

<Steps>
  <Step title="Create a webhook notification channel">
    1. In Dash0, open the notification channel settings and create a new channel of type **Webhook**
    2. Name it `Flashduty`
    3. Paste the complete Flashduty Push URL into **URL**
    4. Flashduty needs no extra request headers, so leave **Additional HTTP Headers** empty
  </Step>

  <Step title="Route check rules to the channel">
    Following Dash0's alert routing settings, send the check rules you want to sync to the `Flashduty` channel. To notify only on critical failures, use Dash0's severity-based routing option.
  </Step>

  <Step title="Verify the lifecycle">
    Let a check rule cross its threshold and confirm Flashduty receives an active alert. Then let the metric return to normal and confirm the same alert recovers. Dash0 sends a fixed JSON body, so no custom payload is needed.
  </Step>
</Steps>

## Alert Key

***

Flashduty uses `data.issue.issueIdentifier` as the Alert Key. Dash0 documents it as the "identifier for the combination of CheckRule and Resource, should remain stable over different issue instances", so trigger and recovery carry the same value.

`data.issue.id` identifies a single issue instance and `data.issue.checkrules[].id` identifies the check rule. Both are kept as labels only and are not part of the Alert Key. Changes to the title, status, description, start time, or check rule version do not change the Alert Key. An alert-type request without `issueIdentifier` is rejected, because later recovery could not be matched.

## Event types and severity

***

| Dash0 `type` | Flashduty handling |
| :- | :- |
| `alert.ongoing` | Trigger or update the alert; severity below |
| `alert.resolved` | Recover |
| `alert.closed` | Recover |
| `alert.superseded` | Ignored; neither creates nor closes an alert |
| Any other value | Ignored; success is returned |

| Dash0 `data.issue.status` | Flashduty severity |
| :- | :- |
| `critical` | Critical |
| `degraded` | Warning |
| Empty or any other value | Warning |

Dash0 does not publish the exact meaning of `alert.closed` and `alert.superseded`. Flashduty handles them conservatively: `closed` is treated as the issue having ended, and `superseded` is assumed to be followed by a new `alert.ongoing` for the same identifier, so it does not change alert state.

## Troubleshooting

***

* **Dash0 gets a non-2xx response**: confirm the Push URL is complete and includes `integration_key`
* **Flashduty returns an invalid-parameter error**: confirm the body is valid JSON and `data.issue.issueIdentifier` is not empty
* **The alert does not recover**: confirm the channel receives recovery notifications (`alert.resolved` / `alert.closed`) and that the check rule's routing does not notify only on critical failures
* **Requests arrive but no alert appears**: `alert.superseded` and unknown types are ignored

For field details, see [Dash0 webhook integration](https://www.dash0.com/hub/integrations/int_alerting_webhook/overview) and [Send Alert Check Notifications](https://www.dash0.com/docs/dash0/monitoring/alerting/send-alert-check-notifications).