Skip to content
Oncallz

Datadog integration

Route Datadog monitor alerts to your on-call rotation

Datadog monitors reach Oncallz through a Datadog webhook with a small custom payload. Triggered alerts page whoever is on call, re-notifications fold into the same incident, and a Recovered notification resolves it.

Set up Datadog → Oncallz in a few minutes

  1. 1 In Oncallz, open Integrations, pick the team, name the integration "Datadog" and click Create. The payload below sends its own dedup_key, so the Duplicate events setting does not matter.
  2. 2 Copy the Inbound URL of the new integration.
  3. 3 In Datadog, open the Webhooks integration tile and add a new webhook. Name it "oncallz", paste the Oncallz URL and put the JSON below in the Payload field. Leave "Encode as form" unticked.
  4. 4 In each monitor that should page, add @webhook-oncallz to the notification message.
  5. 5 Use the monitor's test notification, or let it trigger, and check the incident in Oncallz.

Datadog custom payload

{
  "summary": "$EVENT_TITLE",
  "description": "$EVENT_MSG",
  "severity": "$ALERT_TYPE",
  "status": "$ALERT_TRANSITION",
  "dedup_key": "$ALERT_CYCLE_KEY",
  "source": "$HOSTNAME",
  "link": "$LINK"
}

Oncallz has no Datadog-specific parser; this payload maps Datadog's template variables onto the fields its generic webhook reads. Variable names are from Datadog's Webhooks documentation (September 2026).

How is severity set?

From $ALERT_TYPE. Datadog sends error, warning, info or success, and Oncallz maps error, warning and info directly. Note that Datadog's error becomes an Oncallz error, not critical.

If some monitors should ring phones as critical, create a second webhook such as "oncallz-critical" with "severity": "critical" written into its payload and mention that one in those monitors.

How are duplicates grouped?

$ALERT_CYCLE_KEY stays the same from the moment a monitor triggers until it recovers. Oncallz uses it as the dedup key, so Re-Triggered, Warn, No Data and Renotify messages within one alert cycle are added to the open incident's timeline and raise its occurrence count; they do not page again.

The incident keeps the severity it opened with, so a warning that later becomes an alert stays a warning in Oncallz.

Does it auto-resolve?

Yes, with this payload. When a monitor recovers, $ALERT_TRANSITION is "Recovered", Oncallz reads that status as a resolve and closes the incident with the same cycle key.

Without a dedup_key the Recovered message would carry a different title and could not find the incident, which is why the payload sends one.

What does the on-call engineer receive?

A page on the channels set for that severity. The incident shows the event title, the monitor message from $EVENT_MSG as its description, the host as its source and the full payload, including the Datadog link.

With AI investigation turned on and your own provider key, a summary and probable cause are attached before paging.

Limitations

The integration is one-way. Acknowledging or resolving in Oncallz does not mute or resolve the Datadog monitor, and Datadog downtimes are not visible to Oncallz. Use Oncallz maintenance windows if you also want to hold paging on the Oncallz side.

Frequently asked questions

Is there a native Datadog app for Oncallz?

No. Oncallz works with Datadog through Datadog's standard Webhooks integration. You add a webhook with the Oncallz URL and a short custom payload, then mention @webhook-oncallz in the monitors that should page.

Oncallz has no Datadog-specific parser, so the custom payload is what maps title, severity, status and grouping correctly.

Why do I need a custom payload?

Oncallz reads generic field names such as summary, severity, status and dedup_key. The custom payload puts Datadog's template variables into exactly those fields.

Without it, severity and grouping may not be detected, and a recovery message cannot be matched to the incident it should resolve because its title differs from the triggered one.

Will a Datadog recovery resolve the Oncallz incident?

Yes, if you use the payload on this page. It sends $ALERT_TRANSITION as the status and $ALERT_CYCLE_KEY as the dedup key. When the monitor recovers the status is "Recovered", which Oncallz treats as a resolve for the incident with the same cycle key.

The incident timeline notes that the integration resolved it.

How do I page critical monitors differently from warnings?

Severity comes from $ALERT_TYPE, where Datadog's error becomes an Oncallz error. Oncallz decides per severity which channels to use, such as a phone call for critical and push only for warning.

For monitors that must be critical, add a second Datadog webhook whose payload says "severity": "critical" and mention it instead.

Related pages

Ready when the pager goes off.

Create your workspace in minutes. Free to start, no credit card — $4 per user a month when you’re ready.

Start free