Routing policies

When an alert fires, routing decides which channels get notified — and how alerts are grouped, timed, and renotified.

The tree

Routing is a tree. Alerts walk the tree top-down. The first matching policy wins. Children inherit the parent's defaults unless they override.

A typical tree:

Default — all alerts          (root, catches everything)
├─ Critical only              (matches severity = critical)
│   └─ Payments service       (matches severity = critical AND service = payments)
└─ Info-level                 (matches severity = info)

Form fields

Apply to alerts matching

Label matchers. Empty = match every alert.

The matcher operators are the same as on rules: =, !=, =~, !~.

Send notifications to

Multi-select pills sourced from your channels in Settings → Notification Channels. Pick one or many.

If you don't see the channel you want, click Manage channels → to open Settings in a new tab, add it, then come back and pick it.

Wait this long before the first send

Default 30s. Lets new alerts settle. Avoids notifying on every transient blip.

Combine new alerts within

Default 5m. Alerts that fire within this window get bundled into one notification. Without this, a 50-pod deployment failing all at once would send 50 separate emails.

Renotify if still unacknowledged after

Default 4h. Sends a follow-up to whoever's on call until someone acknowledges.

Auto-mark as expired if not acked within

Default 60 minutes. Cleans up stale acknowledgements so renotification kicks in if the on-call walks away.

Reopen the same incident if it fires again within

Default 120 minutes. Avoids creating a new incident every time a flapping alert toggles on/off — the existing incident reopens with a reopened_count increment.

Group alerts by these labels

Comma-separated label keys. All alerts sharing these label values become one incident. Common: service, cluster.

Without grouping: 50 pod-not-ready alerts → 50 incidents. With grouping by service: 50 alerts → 1 incident per service.

Escalation policy

Optional. If set, when nobody acks the incident within the renotify window, the escalation policy takes over. See Escalation policies.

Continue evaluating sibling policies after a match

Off by default. If on, an alert that matches this policy is also evaluated against the next sibling. Useful for "send to PagerDuty AND log to Slack" patterns.

Priority

Lower number wins when two policies match the same alert. 1 is highest. Use it to put more-specific child policies above less-specific siblings.

Parent policy

The tree position. Defaults to "Root (no parent)". Children inherit the parent's timing knobs unless they override.

Tips

• Start with a single root policy that catches everything and sends to your most general channel. Add child policies as you discover noise.
• The Route Simulator on the Routing tab shows which policies a hypothetical label set would match. Use it to verify a child policy actually overrides the parent.
• Don't over-group. Alerts that affect different services should usually be different incidents.