Docs menu

Prometheus Alertmanager

Alertmanager can deliver Prometheus alerts straight to a Pinglet topic via a webhook receiver — add ?rewrite=alertmanager to the publish URL and Pinglet translates Alertmanager’s grouped-alert payload into a proper push. No glue service needed.

Setup

Add a webhook receiver to your alertmanager.yml and route to it:

route:
  receiver: pinglet

receivers:
  - name: pinglet
    webhook_configs:
      - url: "https://app.pinglet.co.uk/acme/alerts?rewrite=alertmanager"
        send_resolved: true
        http_config:
          authorization:
            type: Bearer
            credentials: "pinglet_<your key>"

Replace acme/alerts with your namespace and preferred topic name — the topic is created on the first alert. Reload Alertmanager, then subscribe to the topic in the Pinglet app using the share link from your dashboard.

To keep the key out of the config file, use credentials_file instead of credentials.

Alertmanager can’t customise its webhook body, which is exactly why the rewrite parameter exists — Pinglet does the translating server-side.

What you’ll receive

One notification per Alertmanager group (as shaped by your group_by settings), not one per alert. The group’s worst firing severity label maps to the message’s level and priority:

Severity Level Priority
critical error urgent — breaks through DND
error error normal
warning warning normal
info / other info normal
Resolved (any severity) success normal

The title is the alert name — HighCPU firing, Resolved: HighCPU, or DiskFull firing (3 alerts) for a group. The body lists each alert’s summary annotation (falling back to description, then the instance label), prefixed with the instance when the group has several alerts. Large groups are capped at five lines with a +N more tail so the push stays within the payload budget.

The card gets up to three badges: the severity, plus the instance for a single alert or the alert count for a group. Scalar context (alert name, status, severity, receiver, instance, job) lands in the metadata sheet on Pro plans.

Only a firing critical is urgent. Warnings and resolutions arrive as standard notifications, so a noisy alert rule won’t hammer through your Do Not Disturb.

With send_resolved: true you’ll get a green Resolved: push when the group clears; set it to false if you only want the bad news.

alert-manager and alert_manager are accepted as aliases for the rewrite value.

Writing alert rules that read well

The rewrite uses the summary annotation as each alert’s line, so a concise, templated summary makes the best push:

groups:
  - name: node
    rules:
      - alert: HighCPU
        expr: 100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100 > 90
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "CPU above 90% for 10 minutes ({{ $value | printf \"%.0f\" }}%)"