Skip to main content
Use a Datadog webhook to send Monitor alerts to Flashduty On-call. Flashduty primarily uses Datadog’s $ALERT_CYCLE_KEY to correlate firing, repeat notification, and recovery events from the same alert cycle.

​
In Flashduty On-call

You can get the integration push URL in either of the following ways.

​
Use a dedicated integration

Choose this option if all alerts go to one channel. It’s the simpler setup.
  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add an integration
  3. Select Datadog, then click Save
  4. Open the generated integration card and copy the Push URL

​
Use a shared integration

Choose this option if you need to route alerts to different channels based on the alert payload.
  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Datadog and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

​
Configure a webhook in Datadog

1

Create a webhook in Datadog

Where: Datadog › Integrations › Webhooks › ConfigurationOn the Webhooks integration page, click New Webhook:
2

Configure the default payload

Where: Datadog › Integrations › Webhooks › Configuration › New Webhook › PayloadEnable the custom payload and paste this JSON:
Different monitor types provide different context, so some variables may be empty. Flashduty ignores empty labels. To drop the Markdown from the Datadog message, replace $EVENT_MSG with $TEXT_ONLY_MSG.
3

Reference the webhook in a monitor

Where: Datadog › MonitorsEdit the monitor that should send alerts and add this to its notification message:
If the webhook uses a different name, replace flashduty with the actual name. After you save the monitor, Datadog calls the Flashduty push URL whenever the alert state changes.
4

Verify trigger and recovery

Where: Datadog › MonitorsPut the monitor into the alert state and confirm Flashduty receives an active alert; then recover the monitor and confirm the same Flashduty alert becomes recovered. Recovery comes from Datadog calling the webhook again on recovery ($ALERT_TRANSITION is Recovered) and needs no separate setup.A Datadog test notification can show that the webhook is reachable (a test body is accepted only if its alert_transition is a supported value), but only a real trigger and recovery verify the full alert lifecycle.

​
Add custom labels

The default payload includes common environment, service, team, and region labels. To send additional Datadog variables, add a custom_labels object at the top level of the payload:
  • custom_labels accepts at most 50 entries; each key becomes a Flashduty label name, so use snake_case
  • Empty values do not create labels
  • Built-in fields take precedence, so a custom label cannot overwrite a non-empty built-in label such as service or check
  • One request can generate at most 50 labels in total, including built-in labels
  • Do not send API keys, tokens, passwords, cookies, or other sensitive information
Do not encode multiple custom labels in a comma-separated string. Label values can contain commas or colons, so a JSON object is required to avoid parsing ambiguity.

​
Alert key

Flashduty primarily uses $ALERT_CYCLE_KEY as the Alert Key. Datadog defines this value as the ID that links events from the time an alert triggers until it resolves, so repeat notifications and recovery events update the same Flashduty alert. If alert_cycle_key is missing or empty, Flashduty generates a random Alert Key for that request instead of rejecting it. The generated value applies only to the current request. A later repeat notification without the same $ALERT_CYCLE_KEY can create a separate alert, while a recovery event without it cannot match and resolve the original alert. Keep $ALERT_CYCLE_KEY in the default payload and treat the random value only as a compatibility fallback. $ID, $ALERT_ID, $AGGREG_KEY, the title, severity, timestamps, and custom labels do not participate in Alert Key generation.

​
Status and severity

Recovery is determined only from $ALERT_TRANSITION and is independent of severity mapping. To change the severity, remap it with an Alert Processing Pipeline.

​
Troubleshooting

  • Datadog does not send a request: Confirm that the Monitor notification message contains the correct @webhook-<name> recipient
  • Flashduty returns an invalid parameter error: Confirm that the payload is valid JSON and contains a non-empty alert_transition value
  • The alert does not recover: Confirm that the firing and recovery payloads contain the same $ALERT_CYCLE_KEY
  • A label is empty: The Monitor or recovery event might not provide that context; select a tag that exists for the Monitor with $TAGS[key]
For the complete variable list, see Datadog Webhooks.