Get updates on the health of your origin where you need them

Health Checks Alerts Move Into the Cloudflare Notifications Dashboard

Cloudflare has integrated Health Checks into the Notifications tab of its dashboard, giving Pro, Business, and Enterprise customers a unified place to manage alerts about origin health. The change means teams no longer have to rely on email to learn when a server fails a monitoring check; they can route those alerts to webhooks, chat platforms, and incident management tools.

Health Checks, first introduced as a lightweight alternative to full Load Balancing configuration, monitor an origin for reachability, responsiveness, correct HTTP status codes, and expected HTTP body content. Checks run from multiple Cloudflare edge locations, so customers can see performance from different geographic vantage points. Until now, the only alerting option was email to up to 20 recipients.

What the Notification Update Adds

The new integration treats Health Checks like any other Cloudflare notification source. Users can create policies from the Notifications dashboard and attach them to one, several, or all configured Health Checks in a single workflow. The Health Check creation page also links directly to notification setup, and each Health Check shows which notifications are already attached to it.

Email alerts haven’t been dropped — they’ve been reformatted with the Health Check name, the time of the alert, and the current health status. But for teams that prefer other channels, the bigger news is webhook support. Webhooks deliver JSON-encoded payloads that can be fed into Slack, Google Chat, Microsoft Teams, internal APIs, or SIEM platforms like Datadog and Splunk. The payload includes fields such as the Health Check name, status, and the reason a check failed, along with a user-friendly text summary.

Notification history is now also available in the dashboard. Enterprise accounts can additionally send Health Check alerts straight to PagerDuty. Because the alerts ride on Cloudflare’s notifications infrastructure, they will automatically pick up new delivery options and features as that platform evolves.

Sending Health Check Alerts to Slack

To get alerts into Slack, the first step is to create a Health Check that watches for the condition you care about. In this example, a check monitors an HTTP endpoint and expects a 200 response code; anything else marks the origin unhealthy.

Next, enable incoming webhooks in the Slack workspace and copy the webhook URL for the target channel. In the Cloudflare dashboard, go to Notifications > Destinations and add a new webhook, giving it a name and pasting the Slack URL. The secret field auto-populates.

After saving, a test message appears in the Slack channel to confirm the connection works. That webhook can then be selected as the destination for a new Health Check notification policy. From then on, any status change — for instance, a response code other than 200 or a recovery back to healthy — posts a message to the channel.

Building a Status Page With Workers and Durable Objects

Webhooks open the door to more custom workflows. One example: a worker using Durable Objects that receives Health Check webhook payloads and renders a live origin status page. The relevant code is available in a public GitHub repository.

The setup starts with wrangler, Cloudflare’s CLI for Workers development. A template scaffolds the project; the included Counter Durable Object class gets renamed to Status in both wrangler.toml and index.mjs.

The worker serves two routes. A /webhook path receives the notification payload and updates stored state. A / path renders a simple status page. The webhook payload’s data object carries the Health Check name, status, and failure reason; the text field contains the same information in a human-readable form, but is more difficult to parse programmatically, so the status page uses the structured fields.

A fetch method inside the durable object routes requests to the right handler and returns an error for unknown paths; the worker’s own fetch handler exposes the durable object to the internet.

Deploying and Testing

Publishing requires one command:

$ wrangler publish --new-class Status

To test, create a webhook in Notifications > Destinations pointing to the worker’s deployed URL, then attach that webhook to a Health Check notification policy. Before any alerts fire, the status page simply displays the page title. Taking the origin down triggers the webhook, and the page updates to show the Health Check name, an “Unhealthy” status, and the failure reason — in the example, a TCP connection failure. Restoring the origin brings the page back to a “Healthy” state with “No failures.” Additional Health Checks tied to the same webhook automatically appear on the page.

Authenticating Webhook Requests

An exposed webhook URL allows anyone to push forged data to the status page. To prevent that, webhooks support a shared secret. Generate one — for example, a UUID via Python — and create a new webhook destination with that secret included.

Pass the same secret to the worker using wrangler’s secret command, which prompts for the value and stores it securely. Every webhook request then carries the secret in the cf-webhook-auth header. The worker’s handleWebhook function compares that header value against the configured secret and rejects requests that don’t match.

This status page is just one illustration of what webhooks enable. The same mechanism that can push a notification into Slack can feed a custom application, an internal dashboard, or any other system that can parse a JSON POST request — giving teams control over where and how they learn about origin outages.

Health Check Alerts: A New Home

Cloudflare has consolidated its alerting tools under the Notifications dashboard, and Health Checks are following suit. Notification configuration is moving away from the Health Checks interface and into this centralized location, where most other Cloudflare services already manage their alerts. Existing customers who set up email alerts through the legacy system will have a three-month transition period before the old infrastructure is retired.

The shift happens in stages. For now, legacy emails continue to arrive exactly as before — any existing parsing or automation built around them will keep working. Inside a Health Check, admins will see both the older notification format and a direct link to the Notifications dashboard. On May 24, 2022, the legacy method of configuring email notifications from the Health Checks dashboard will be disabled. Then, on June 28, 2022, legacy email delivery stops entirely, and adding new emails through the /healthchecks endpoint will no longer trigger email alerts.

Admins relying on the legacy system are advised to move their Health Checks notifications to the Notifications dashboard before that cutoff to avoid missing any alerts. The overlap period is meant to give teams ample time to reconfigure their notification preferences without an interruption in service.