Webhook-Based Alerting: Connecting Prometheus and Grafana Without an Integration Project

The word "integration" suggests something that takes an integration engineer and a sprint of work. For connecting a monitoring tool to a paging tool, that's rarely true — most monitoring systems already speak webhook natively, and the actual work is usually just pointing them at the right URL with the right payload shape.

Prometheus Alertmanager

Alertmanager already supports webhook receivers as a first-class notification method — there's no plugin to install. A webhook_configs block in Alertmanager's routing configuration, pointed at a paging tool's webhook endpoint, is enough for firing alerts to reach that endpoint as an HTTP POST with a JSON body describing the alert, its labels, and its current state.

The part worth getting right is severity mapping. Alertmanager alerts carry a severity label that's whatever the person writing the alerting rule chose to call it — often critical, warning, or page, but not standardized beyond convention. On the receiving end, that label needs to map to an actual page priority, or every Alertmanager alert ends up treated identically regardless of how the rule author intended it.

Grafana alerting

Grafana's built-in alerting engine (separate from, though often paired with, Prometheus) supports webhook contact points directly in its alerting configuration. A contact point pointed at a paging tool's webhook URL means firing alerts trigger a page the same way an Alertmanager webhook does — no separate plugin, just a contact point pointed at the right place.

One detail worth checking: Grafana's webhook payload shape is its own format, distinct from Alertmanager's, even when Grafana is technically evaluating rules sourced from Prometheus data. A paging tool needs to actually parse Grafana's specific JSON structure, not just any webhook shape, for the integration to carry through useful detail like the dashboard panel or the metric that triggered the alert.

What a good receiving end does with the payload

Accepting a webhook POST is the easy half. What separates a working integration from a merely connected one is what happens with the payload after it arrives:

• Mapping severity to priority, so a critical Alertmanager alert and a warning one don't get treated the same.
• Carrying through the alert's summary and labels into the page itself, so the on-call responder sees what's actually firing without needing to open a separate dashboard first.
• Resolving alerts automatically when Alertmanager or Grafana sends the corresponding "resolved" webhook, so a page doesn't sit open after the underlying issue has already cleared.
• Deduplicating repeated fires of the same alert, so a flapping condition doesn't generate a fresh page every few minutes.

PingParrot's webhook receiver

PingParrot accepts webhook payloads from both Alertmanager and Grafana directly — no custom middleware or translation layer required — mapping severity labels to page priority and carrying through the alert summary so the page itself is useful on its own. Setup is genuinely just adding a webhook URL to Alertmanager's config or a Grafana contact point, generating an API key from the PingParrot dashboard, and confirming a test alert fires correctly.

The broader point extends past Prometheus and Grafana specifically: any monitoring tool that supports outbound webhooks — which is most of them at this point — can be wired into a paging tool the same way. The barrier most teams imagine, a dedicated integration project, usually doesn't exist. It's a webhook URL and a payload format, most of an afternoon at worst.