How to Update a Customer Status Page Automatically from Grafana Alerts

Your Grafana alerts are firing. Your on-call engineer gets paged. The incident is acknowledged, a fix is deployed, and the service recovers — all within twenty minutes. Meanwhile, your customers are still hitting your support inbox asking "is something wrong?" because your status page says "All Systems Operational" throughout the entire incident.

This is the gap that exists in almost every monitoring setup. Internal tooling fires fast and routes intelligently, but external communication lags behind by hours, or gets skipped entirely. The fix is not adding another manual step to your runbook. The fix is connecting your alerting pipeline to your status page so updates happen automatically.

This post shows you exactly how to do that with Grafana and Alert24.

The Architecture in Two Sentences

Grafana fires a webhook to Alert24 when an alert transitions state. Alert24 maps that alert to a service on your status page, updates the service's health, and publishes the change to your public timeline — no human intervention required.

Your team still owns the incident. The status page just stays honest without anyone having to remember to update it.

Step 1: Create a Contact Point in Grafana

In Grafana, navigate to Alerting > Contact points and create a new contact point. Choose "Webhook" as the type.

Set the URL to your Alert24 webhook receiver endpoint, which follows this pattern:

https://app.alert24.com/webhooks/inbound/grafana/{your-token}

You can find your token by going to Alert24 > Integrations > Grafana and copying the receiver URL. Each token is scoped to a workspace, so alerts from multiple Grafana instances can funnel into the same Alert24 workspace if needed.

For authentication, Alert24 accepts the token in the URL path, so no additional headers are required. If your Grafana instance is behind a firewall, you can optionally add a shared secret in the optional auth header field and configure Alert24 to validate it.

The contact point configuration in Grafana's provisioning format looks like this:

apiVersion: 1

contactPoints:
  - orgId: 1
    name: Alert24 Status Page
    receivers:
      - uid: alert24-webhook
        type: webhook
        settings:
          url: https://app.alert24.com/webhooks/inbound/grafana/YOUR_TOKEN_HERE
          httpMethod: POST
          maxAlerts: 0
        disableResolveMessage: false

Set disableResolveMessage: false — this is critical. Alert24 needs to receive the resolved state to automatically move your service back to operational. If you suppress resolve messages, the status page will stay degraded until someone manually clears it.

Step 2: Map Grafana Alert States to Service Status

When Alert24 receives a Grafana webhook payload, it maps the status field to a service health state on your status page. The default mapping is straightforward:

You can override this mapping per-alert by adding labels to your Grafana alert rule. For example, if you want a specific alert to show as "Partial Outage" rather than "Degraded Performance," add the label alert24_status: partial_outage to the alert rule in Grafana.

In Grafana's alert rule editor under Labels, add:

alert24_status = partial_outage
alert24_service = payment-api

The alert24_service label tells Alert24 which service on your status page to update. If you omit it, Alert24 uses the alert name to fuzzy-match against your configured services, but explicit mapping is more reliable in production.

Step 3: Link Grafana Alerts to Status Page Services

In Alert24, go to Status Page > Services and open the service you want to connect. Under Integrations, select "Grafana" and specify the matching criteria — either the service slug you're passing in labels, or an alert name pattern.

You can link multiple Grafana alerts to a single service. This is useful when a service depends on several underlying systems: if your database alert fires or your cache alert fires, both should update the same "API" service on your status page.

The service configuration supports a simple priority model: if multiple alerts are simultaneously firing, the service shows the most severe state. If the database alert clears but the cache alert is still firing, the service stays degraded until all linked alerts resolve.

What Customers See

When an alert fires, Alert24 posts an incident to your public status page timeline with a timestamp and a description derived from the Grafana alert name and annotations. The incident entry looks like:

2026-05-28 14:32 UTC — Payment API is experiencing degraded performance. We are investigating.

When the alert resolves, Alert24 closes the incident automatically:

2026-05-28 14:51 UTC — Payment API has recovered. All systems operational.

The total incident duration appears on the timeline so customers can see how long the impact lasted. You do not need to write either of those messages manually.

If you want to add context during a live incident — a more specific description, a workaround, or an ETA — you can update the incident from Alert24 or from your mobile app. Those updates appear in the timeline as separate entries beneath the auto-generated ones.

Handling Flapping Alerts

Grafana alerts can flap: firing, resolved, firing again within minutes. Without any dampening, this produces a noisy status page timeline with multiple open-and-close cycles in quick succession.

Alert24 handles this with a configurable resolve delay. When an alert resolves, Alert24 waits a short window (default: 3 minutes) before marking the service operational and closing the incident. If the alert fires again during that window, the incident stays open and a new entry is added to the timeline instead of creating a second incident.

You can adjust the resolve delay in Alert24 > Settings > Webhook Receivers per contact point. For highly volatile alerts, increase it. For alerts where fast recovery is meaningful (like a brief network blip), lower it or disable it.

Notification Routing Stays Separate

One point worth being explicit about: this webhook integration handles the status page only. Your on-call routing, escalation policies, and engineer notifications are configured separately in Alert24 under On-Call Schedules and Alert Routing.

You do not have to choose between sending Grafana alerts to your on-call team and sending them to your status page. Both happen from the same contact point. The webhook receiver updates the status page; Alert24's routing engine simultaneously pages the right person. These are parallel paths, not competing ones.

Next Steps

To get this running in your environment:

1. Create the Alert24 contact point in Grafana using the YAML block above with your actual token.
2. Add the contact point to a notification policy so it fires alongside your existing PagerDuty or Slack contact points, not instead of them.
3. In Alert24, create a service for each customer-facing system you want to expose on the status page.
4. Link each service to the corresponding Grafana alert rules using the alert24_service label.
5. Do a test by manually triggering a Grafana alert in a non-production environment and confirming the status page updates within 30 seconds.

If you are starting from scratch and do not yet have a public status page configured, Alert24's setup wizard walks through creating one at your own subdomain or custom domain. The Grafana integration is available on all plans.