How to Update a Customer Status Page When Datadog Detects an Outage

The Gap Between Internal Monitoring and Customer Visibility

Your Datadog dashboards are green. Then they're not. You get the Slack ping, your engineers jump on a call, and within minutes you have a working theory about what's broken. That part works.

What doesn't work: your customers are already filing support tickets because they noticed the problem before you told them about it. Your status page still shows "All Systems Operational" because updating it requires someone to context-switch out of the incident, log into a separate tool, and write something customer-facing while the fire is still burning.

This is a solved problem, but the solution requires a small amount of plumbing that most teams never set up. Here's how to close the gap: Datadog fires a webhook the moment an alert triggers, Alert24 receives it, maps it to the right service, and your public status page flips to "Investigating" automatically — before any engineer has to touch anything.

How the Integration Works

Datadog's alerting system supports webhook notifications alongside its native integrations. When a monitor transitions to an alert state, Datadog can POST a JSON payload to any URL you specify. Alert24 exposes an incoming webhook receiver that accepts this payload, parses the monitor name and status, and updates the linked service on your status page.

The flow looks like this:

1. A Datadog monitor breaches its threshold (error rate, latency, host down, etc.)
2. Datadog fires a webhook POST to your Alert24 incoming webhook URL
3. Alert24 matches the payload to a service on your status page
4. The service status changes to "Investigating" and the incident opens
5. Your team adds customer-facing updates as the incident progresses
6. When the monitor recovers, Datadog sends a recovery payload and Alert24 resolves the incident

Steps 1 through 4 happen in seconds, with no human in the loop.

Setting Up the Datadog Webhook

In Datadog, go to Integrations > Webhooks and add a new webhook. Give it a name — something like alert24-status-page — and paste your Alert24 incoming webhook URL.

The URL comes from your Alert24 account under Services > [Your Service] > Incoming Webhooks > Add Webhook. Copy that URL before continuing.

For the payload, use the following template. This gives Alert24 enough context to route the notification correctly:

{
  "monitor_id": "$ID",
  "monitor_name": "$MONITOR_NAME",
  "status": "$ALERT_STATUS",
  "message": "$TEXT_ONLY_MSG",
  "severity": "$ALERT_TRANSITION",
  "url": "$LINK",
  "host": "$HOSTNAME",
  "tags": "$TAGS"
}

Datadog substitutes these template variables at send time. $ALERT_STATUS will be "Triggered" when an alert fires and "Recovered" when it clears. Alert24 uses that field to decide whether to open or resolve the incident.

If you have monitors grouped by service — say, a group of monitors covering your API and another covering your payment processor — you can add a custom tag like service:payments to the Datadog monitors and Alert24 will use that tag to route the webhook to the correct status page service.

Mapping Datadog Monitors to Status Page Services

In Alert24, each service on your status page can have one or more incoming webhook sources attached to it. When a webhook arrives, Alert24 checks the payload for a service hint in this order:

The simplest setup is one webhook URL per service. Create a separate incoming webhook endpoint for your API service and another for your payments service. Then in Datadog, configure the API monitors to notify the API webhook URL and the payment monitors to notify the payments one.

If you have dozens of monitors, the tag-based routing is cleaner. Tag each Datadog monitor with a service: tag matching the slug of your Alert24 service, and use a single webhook URL for all of them.

What Happens on Your Status Page

Once the webhook fires and Alert24 receives it, the status page updates immediately. The service moves from "Operational" to "Investigating," and an incident is created with a timestamp and the raw monitor message as an internal note.

Your customers see something like this on the public status page:

API — Investigating We are aware of an issue affecting API performance and are investigating. — 14:23 UTC

That first line is automatic. No one wrote it; Alert24 generated it from the monitor name and a configurable template.

From there, your engineers own the customer-facing narrative. Inside the Alert24 incident view, you can post updates that go directly to the status page — and optionally trigger email or SMS notifications to subscribers. The typical cadence is an acknowledgment within 5 minutes, a diagnosis update within 30, and a resolution note when the incident closes.

Automatic Recovery

When Datadog's monitor recovers, it sends another webhook with "status": "Recovered". Alert24 catches this, closes the incident, and moves the service back to "Operational." If your team hasn't posted a resolution note yet, Alert24 can post a default one automatically — configurable per service.

This means the entire incident lifecycle, from detection to recovery, can complete on the status page without anyone manually updating it. In practice, your team will almost always add at least one human update during the incident. But the open and close happen automatically, which eliminates the most common failure modes: forgetting to update the status page at all, or forgetting to mark the incident resolved after things recover.

Testing Before You Go Live

Before you attach this to a production monitor, test the integration with a low-severity monitor or a manual webhook POST. You can send a test payload from the Datadog webhook configuration page, or use curl:

curl -X POST https://app.alert24.io/hooks/incoming/YOUR_TOKEN \
  -H "Content-Type: application/json" \
  -d '{
    "monitor_id": "test-001",
    "monitor_name": "Test Monitor",
    "status": "Triggered",
    "message": "This is a test alert from Datadog.",
    "severity": "Alert"
  }'

You should see the linked service flip to "Investigating" within a few seconds. If it doesn't, check the incoming webhook log in Alert24 under Services > Incoming Webhooks > Recent Activity — it shows the raw payload and any parsing errors.

Next Steps

The integration is straightforward to configure, but the value compounds over time. Once your engineers know the status page updates automatically, they stop treating it as an afterthought. Customers trust it more because it's accurate. Support ticket volume during incidents drops.

To get started:

1. Create your services in Alert24 if you haven't already
2. Add an incoming webhook endpoint to each service
3. Add the Datadog webhook integration pointing at those URLs
4. Tag your Datadog monitors with service: tags if you're using shared routing
5. Run a test payload to confirm the integration works end to end

If you're already using Datadog for monitoring, this takes about 20 minutes to set up and removes a manual step from every future incident.