Metrics & monitoring

Send Prometheus Alertmanager alerts to on-call with CallHeim.

Alertmanager webhook receiver (firing/resolved groups). CallHeim maps the payload, collapses repeats within five minutes, and pages whoever is on call for the service it belongs to.

prometheusalso accepts: prom

Alertmanager groups

A group is split into one alert per member. If several alerts from one group are on the same incident, it stays open until every one of them has recovered.

Alerts fired by Prometheus's Alertmanager become CallHeim alerts: repeats of the same alert collapse onto one incident, and the service the integration is bound to pages whoever is on call for it. CallHeim includes a payload mapping for Alertmanager’s webhook format, built and tested against sample payloads. Alertmanager can also be pointed straight at this same URL with source=alertmanager if you run it without a separate Prometheus server in front.

How the alert reaches on-call

  1. Step 1Prometheus evaluates an alerting rule and hands it to Alertmanager, which groups it with other alerts sharing the same labels.
  2. Step 2Alertmanager POSTs the group as one JSON body to your CallHeim ingest URL, on the interval its route config sets.
  3. Step 3CallHeim splits the group into one alert per member and maps each alert's severity label.
  4. Step 4Repeats of an alert (by its own Alertmanager fingerprint) within five minutes collapse onto one incident, and alerts from one group that fire together can share an incident.
  5. Step 5The integration's bound service selects an escalation policy, which pages the on-call tier.

Setting it up

  1. 01

    Add a webhook_configs receiver to Alertmanager's configuration.

    Create the Prometheus Alertmanager integration in CallHeim first to get the exact ingest URL.

  2. 02

    Set send_resolved: true on the receiver.

    This makes Alertmanager POST again when alerts resolve, which is what resolves the incident — see Recovery below.

  3. 03

    Route alerts to the receiver.

    Add a route (or route tree) that matches the alerts you want paged to the receiver name you configured.

  4. 04

    Reload or restart Alertmanager to apply the config.

Example payloadJSON
{
  "version": "4",
  "groupKey": "{}:{alertname=\"HighRequestLatency\"}",
  "status": "firing",
  "receiver": "callheim",
  "commonLabels": { "alertname": "HighRequestLatency", "severity": "critical" },
  "alerts": [
    {
      "status": "firing",
      "labels": { "alertname": "HighRequestLatency", "severity": "critical", "instance": "api-1:9090" },
      "annotations": { "summary": "High request latency on api-1", "description": "p99 latency is 850ms (> 500ms) for 5m" },
      "startsAt": "2026-06-27T10:00:00Z",
      "fingerprint": "a1b2c3d4e5f6"
    }
  ]
}
Example shape written by us, matching Alertmanager's documented webhook_config format; check the Alertmanager documentation for the current schema.

What CallHeim reads from the payload

Payload fields and what each one maps to on the incident
Payload fieldMaps toNote
annotations.summary / labels.alertname / annotations.descriptionincident title
labels.severityseveritycritical→P1, warning→P3, info→P4; a severity label literally set to "page" also maps to P1.
annotations.description / summary / messageincident body
alerts[].fingerprintidentity signalAlertmanager's own per-alert fingerprint is stable across a firing→resolved pair, which is what lets a later resolved notification find the same incident.

How CallHeim processes it

Routing

Each alert source is bound to a service, and the service’s escalation policy (or its team’s) sets who is paged.

Deduplication

Repeats of the same alert collapse onto one incident while they keep arriving within five minutes of each other. A repeat that arrives after a longer quiet gap opens a new incident. The fingerprint is Alertmanager's own per-alert fingerprint when present, else the group key, else the alert name and instance — so the same alert re-firing collapses even across a resolve/fire pair.

Recovery

When Alertmanager sends a resolved notification, CallHeim resolves the incident. If several alerts from one group are on the same incident, it stays open until every one of them has recovered. Checked with a real Alertmanager (v0.28.1) on 26 September 2026, including groups where one alert recovers while another is still firing. An incident that also holds an alert which never sends a recovery stays open until a person resolves it.

Troubleshooting

Common problems and how to fix them
ProblemFix
An incident stays open after an alert resolved.Expected while another alert on the same incident is still firing — it resolves when the last one recovers (see Recovery above). If every alert has recovered, check that send_resolved: true is set on the receiver, or resolve it by hand.
HTTP 400 on send.Check the Alertmanager version — the webhook payload schema (fields like values) changed between major versions.
Alerts page with no summary text.The alerting rule has no summary or description annotation, so the title falls back to the bare alertname.
No alerts ever arrive.Confirm the route actually matches to this receiver — Alertmanager's default route can silently absorb alerts that do not match a more specific route first.
HTTP 401 once you enabled signing.A static header from Alertmanager's http_config can't satisfy a per-request HMAC signature — leave CallHeim's signing off for this integration unless you add a proxy in front that can compute and add the header per request.

Security

CallHeim verifies an HMAC-SHA256 signature on each source’s requests once you enable signing on that integration (the sending tool must be able to sign). Alertmanager's webhook_config.http_config can send a static custom header (http_headers), but a static value can never be a valid per-request HMAC-SHA256 signature of a changing body — leave CallHeim's signing off for a direct Alertmanager webhook and rely on the ingest URL itself as the credential, unless you add a signing proxy in front that can compute the header per request.

Vendor documentation checked

The thresholds it passes through

Dedup window
300s
Flap threshold
4 transitions / 600s
Title correlation
similarity ≥ 0.6, same source and service
Group window default
600s

All defaults are published. You can turn title correlation off or change its threshold, and set the window on your own noise rules; the dedup window and the flap settings are fixed. How alerts are processed →

CallHeim

Point Prometheus Alertmanager at CallHeim and see what it does with your alerts.

Explore the platform, connect one source, and send yourself a test page by e-mail (early access).

Explore the platformAll integrations

Early access · every workspace starts with a 14-day trial for up to 5 seats, no card required