How to Send a Datadog Monitor Alert to a Shared Phone Room

To send a Datadog monitor update to a shared phone Room, create a PingRoom incoming webhook, add its secret URL as a Datadog webhook integration, paste the fixed payload and idempotency header below, then add @webhook-<name> to one monitor.

This is a webhook recipe, not a native Datadog integration. Datadog remains the source of truth for the monitor and incident. PingRoom carries one short shared signal to the people in the Room.

Choose the delivery route first

Use PingRoom when a small group needs a simple shared Triggered, Recovered, or No Data signal. Use Datadog mobile push and On-Call when responders need paging, critical alerts, escalation, acknowledgement, or full incident context. Datadog also supports native routes such as Slack, Microsoft Teams, PagerDuty, ServiceNow, and webhooks through its monitor notification controls.

Datadog features vary by site, organization, and permissions. Confirm the available routes with your Datadog administrator before changing a monitor.

Create one private destination

Open your PingRoom Rooms, choose a private Room, then open Settings → Connections → From another app.

1. Select Add Webhook.
2. Name it Datadog monitor.
3. Keep Quick Ping on Custom message.
4. Save it and copy the webhook URL.

The Room owner needs PingRoom Pro. A Room can have up to four incoming webhooks. The URL contains the secret, so keep the whole value out of source control, screenshots, tickets, and monitor text. Regenerate it if it leaks.

For the complete request and error contract, read the incoming-webhook reference. A successful API response means PingRoom accepted and queued the Ping; it does not guarantee what every phone displays under every network, Focus, mute, or notification setting.

Add the Datadog webhook

Open Datadog's Webhooks integration tile and create a webhook with a short name such as pingroom-shared-monitor. Paste the PingRoom URL into the URL field.

Use this custom payload:

{
  "title": "Datadog monitor update",
  "message": "Status: $ALERT_TRANSITION",
  "correlation_id": "datadog-$ALERT_CYCLE_KEY"
}

Use this custom header:

{
  "Idempotency-Key": "datadog-$ID"
}

Datadog's webhook reference documents $ID as the event identity, $ALERT_CYCLE_KEY as the identity connecting a trigger through its recovery, and $ALERT_TRANSITION as the state change. PingRoom uses the event ID to deduplicate an exact retry, while the correlation ID keeps related transitions grouped for connected systems.

The phone copy deliberately omits the monitor title, query, scope, tags, host, log sample, dashboard link, and event text. Those details stay in Datadog. The ready-to-test template and deterministic verifier are recorded in this article's production receipt.

Attach it to one monitor

Edit the selected monitor's notification message and add:

@webhook-pingroom-shared-monitor

Start with one low-volume monitor. Do not add the webhook to every monitor or a broad notification rule before you know how often the Room will fire.

Then run a controlled rehearsal:

1. Trigger the monitor with a safe test condition.
2. Confirm one Room Ping arrives with Status: Triggered.
3. Restore the test condition.
4. Confirm the related update arrives with Status: Recovered.
5. Compare both events with Datadog. Datadog, not the Room, decides the actual monitor state.

If a required variable is empty in your test, stop and adjust the template for that monitor type or place a relay between Datadog and PingRoom. Do not publish a signal whose identity you have not verified.

At our miniature rehearsal bench, Pingo—PingRoom's fictional CMO—watches the trigger marker rise and the recovery marker settle. The two humans still configure and test every step. Pingo has no Datadog or Room access and sends nothing.

Know what the direct path cannot do

Datadog documents retries for its internal errors, missed connections, and 5XX responses. A direct 429 or another non-5XX response may not receive the same retry treatment. If losing a transition is unacceptable, put a durable queue and relay in front of PingRoom and keep your pager route independent.

The inspected Datadog webhook documentation does not describe a request-signing scheme for this outbound path. The secret PingRoom URL is the credential. Use a relay if you need another authentication check, a sender allowlist, durable delivery, field transformations, or routing across several Rooms.

Datadog also documents restrictions on sending some security notifications through webhooks for HIPAA-enabled accounts. Follow Datadog's current product guidance rather than using this recipe to bypass that boundary.

PingRoom's cooldown and Room rate limits still apply. Keep the monitor in Datadog, keep paging in the system your team trusts, and let the Room carry only the shared state change people need to notice.

If that boundary fits, create the private destination Room, add one webhook, and test one harmless trigger and recovery before you rely on it. The generic webhook-to-push guide explains the PingRoom response in detail, while the monitoring routing guide covers ownership and severity.

The two editorial illustrations in this article were created with AI using approved PingRoom character references and reviewed by the PingRoom team.