Skip to main content
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.

In Flashduty On-call

Create either a dedicated or shared Dash0 alert integration and copy its complete Push URL.

Configure Dash0

1

Create a Webhook notification channel in Dash0

Where: Dash0 › Settings › Notification Channels › Add › WebhookSave the channel.
2

Use the channel in a check rule

Where: Dash0 › create or edit a check rule › Notifications › Channels › Add notification channelTo notify only on critical failures, use Dash0’s severity-based routing option.
3

Send a test notification and verify with a real alert

Where: Dash0 › Settings › Notification ChannelsIn the channel list, click Send test notification on the Flashduty channel. The test notification only proves the Push URL is reachable: Flashduty returns success for event types Dash0 does not document, without creating an alert. To verify the full flow, 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. A few seconds later the integration in Flashduty shows a Latest event time, which means setup works.

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 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 and Send Alert Check Notifications.