ClawdCall

Turn a critical Datadog monitor webhook into a phone call

Use Datadog Renotify to call one on-duty owner only after a production P1 persists. This webhook recipe filters transient alerts, prevents duplicate calls, captures a spoken acknowledgment, and writes the result back to your incident path.

Independent guide; not affiliated with Datadog. Test with your own number first. Calls may use minutes.

01P1 persists
02Check impact
03Call on-duty owner
04Update incident

The event

Wait for a persistent critical state

A critical production monitor reaches Renotify.

The checks

Confirm impact and ownership

Customer impact is confirmed, nobody has acknowledged the incident, and this alert cycle is new.

After the call

Return acknowledgment to the incident path

Write the owner, acknowledgment, and next action back to the incident.

How do you turn a Datadog webhook into a phone call?

Put the webhook mention inside Datadog's is_renotify block so the first alert stays in your normal channels. A private bridge then verifies the request, checks that the production P1 still affects customers, rejects duplicate alert cycles, and asks ClawdCall to phone a trusted recipient. The spoken answer returns to your incident path.

Decision guide

Choose the right Datadog phone escalation path

All three routes can be valid. Choose based on whether you need native on-call management, a cross-tool incident platform, or one focused conversational webhook call.

Best for

Datadog On-Call

Native schedules and escalation policies. Use it when teams want phone calls, notification preferences, routing rules, and acknowledgment inside Datadog.

Best for

PagerDuty + Datadog

Mature cross-tool incident response. Use it when PagerDuty already owns services, schedules, escalation, and response across multiple monitoring systems.

Best for

ClawdCall webhook

A custom spoken brief and structured answer. Use it to call one trusted owner after Renotify, collect a constrained reply, and return the outcome without replacing your on-call schedule.

Call rules

Call only when

  • The transition is Renotify, not the first alert
  • Priority is P1 and environment is production
  • Customer impact is confirmed and the incident is unacknowledged
  • The alert-cycle key has not triggered a call

Example message

What they hear

“Checkout is still critical and affecting customers. Say investigating or request backup.”

Setup

Connect the pieces

  1. 01

    Create a private webhook bridge and store both tokens in a secret manager.

  2. 02

    Add the downloadable payload to Datadog Webhooks and authenticate the bridge.

  3. 03

    Put @webhook-<name> inside an is_renotify block.

  4. 04

    Map impact, service, and owner from trusted tags, then make one test call.

Code

Datadog call rules

export function shouldEscalate(event, wasAcknowledged, wasProcessed) {
  const customerImpact = String(event.customer_impact).toLowerCase() === "true";
  const ownerKnown = String(event.owner_known).toLowerCase() === "true";

  return Boolean(
    event.alert_transition === "Renotify" &&
    event.alert_priority === "P1" &&
    event.environment === "production" &&
    customerImpact &&
    ownerKnown &&
    !wasAcknowledged(event.alert_cycle_key) &&
    !wasProcessed(event.alert_cycle_key, event.alert_transition)
  );
}

// Recheck the current monitor/incident state before calling.
// Build speech from safe allowlisted fields, never raw logs or signed URLs.

First run

Try it without a live event

  1. Send the sample Renotify event to the bridge in dry-run mode.
  2. Change Renotify to Triggered and confirm that no call is created.
  3. Call your own number once, then replay the cycle key and confirm no second call.
Test with your own number

Before it goes live

Keep the call focused

  • Wait for Renotify so brief spikes stay in normal alert channels.
  • Keep logs, traces, customer data, tokens, and private URLs out of the call.
  • Route from trusted configuration and allow one call per alert cycle.

Handling the result

Write the call acknowledgment back to the Datadog incident path

Use the alert-cycle key to join the monitor, call, and incident update.

  1. 01

    Save the alert-cycle key, monitor ID, and call ID together.

  2. 02

    Authenticate the callback and check that the monitor is still critical.

  3. 03

    Update the incident once. Ignore results after recovery or acknowledgment.

Datadog workflow FAQ

Common setup and handoff questions

Can Datadog make phone calls for critical alerts?

Yes. Datadog On-Call supports phone calls as a notification method and is the natural choice when you want native schedules, routing rules, and escalation policies. This independent recipe is for a custom conversational call from a monitor webhook.

How do I turn a Datadog monitor webhook into a phone call?

Add the webhook mention inside an is_renotify block. The bridge should authenticate the request, validate the exact transition, recheck the monitor state, map a trusted recipient, reject duplicate alert-cycle keys, and then create the call.

Do I need PagerDuty for Datadog phone alerts?

No. Datadog On-Call can provide native phone notifications, and ClawdCall can handle a focused custom call from a webhook. PagerDuty remains a strong option for mature cross-tool schedules, routing, and incident response.

How is this different from Datadog On-Call?

Datadog On-Call manages native schedules, routing, escalation policies, and notification preferences. ClawdCall focuses on a short spoken brief, collecting a constrained answer, and returning that structured outcome to your workflow; it is not a full on-call management system.

How do I call only after a Datadog alert is renotified?

Configure the monitor's renotification interval, place the webhook mention inside {{#is_renotify}}, require the Renotify transition in the bridge, and recheck that the monitor is still critical before creating the call.

Sources

Documentation used for this recipe