Alert routes

Alert routes decide what happens to an alert when it arrives: whether it opens an incident, who gets paged, and whether it is ignored. Without any routes, every new alert opens an incident, and paging follows your Auto-Escalation by Severity rules, then your global fallback escalation path.

Routes are managed by workspace admins under On-Call → Routes.

How routes are evaluated

• Routes are checked from top to bottom. The first enabled route that matches decides what happens, and the rest are ignored.
• A route matches only when every filter you set on it matches. A filter you leave empty matches everything.
• If no route matches, the alert gets the default treatment: an incident is created, and the escalation path comes from Auto-Escalation by Severity, then your global fallback.
• Drag routes to reorder them. Put specific routes above general ones.

Only alerts that are new are routed. A repeat of an alert that already exists is deduplicated instead.

What a route can match

Filter	Matches
Alert sources	Prometheus, Grafana, CloudWatch or Generic. Empty means all sources.
Severity filter	One or more of critical, warning and info. Empty means all severities. The editor also lists high and low, but alerts always arrive as critical, warning or info, so a filter on high or low never matches.
Label filters	Labels on the alert, such as env or service.
Annotation filters	Annotations on the alert, such as summary.
Alert content	The alert's title and description.

For labels and annotations, the value you enter can be:

• An exact value or pattern. Values are regular expressions in RE2 syntax, so prod matches any value containing prod, and ^prod$ matches only prod. Use ^ and $ when you want an exact match.
• *, which matches any value as long as the label is present.

Lookaheads and backreferences are not supported. If a pattern is not valid, that route never matches, so test it before relying on it.

Where the title and description come from depends on the source:

Source	Title	Description
Prometheus	the alertname label	the summary annotation
Grafana	the rule name	the summary annotation
Generic	the title field	the description field

What a route can do

Action	Effect
Create incident	Open an incident for matching alerts.
Escalate	Page through a specific escalation path, or through a team (below).
Suppress alert	Keep the alert on record but open no incident and page no one.
Severity override	Open the incident at a different severity than the alert arrived with. Choose critical, warning or info: other values are treated as warning. The alert itself keeps its original severity.

Which escalation path is used

Regen picks the escalation path for an alert in this order:

1. The matching route's own escalation path, if the route picks one.
2. Otherwise, the Auto-Escalation by Severity rule for the alert's severity.
3. Otherwise, the global fallback path.

A path chosen on a route always takes priority over Auto-Escalation by Severity for the alerts that route matches. Auto-Escalation by Severity and the global fallback are set up on the escalation paths page.

Escalating to a team

Choosing Team sends the alert to whichever escalation path that team owns. If the team owns no path, or more than one, the team setting is ignored and the alert follows the default rules. The incident is still created, so an alert is never lost to a misconfigured team.

If you choose both a specific path and a team, the specific path wins.

When nobody is paged

If an alert has no escalation policy from its route, its severity or the global fallback, the incident is still created, but nobody is paged, and the incident records that. Set a global fallback escalation policy so that this cannot happen silently.

Test a route

The route editor has a Test this route section. Enter a sample alert (source, severity, title, description, and labels and annotations as JSON) and choose Run test. It tells you whether the alert matches the route. It is a dry run: it never creates an incident or sends a page. Use it before saving, especially when you are using regular expressions.

Examples

Page the database team for production database alerts

• Label filter: service = postgres.*, env = prod
• Action: Escalate → Team → Database

Ignore a noisy test environment

• Label filter: env = staging
• Action: Suppress alert

Treat any alert mentioning out-of-memory as critical

• Alert content, description: .*OOM.*
• Action: Severity override → critical

Related

• Alert deduplication
• Grouping rules: combine related alerts into one incident.
• Escalation paths