Skip to main content
Routing decides which team a new incident goes to and which escalation policy it takes. Open Alerts → Routing. Viewing requires alerts.routing.read; changing routing rules and team on-call policies requires alerts.routing.manage.

​
Which incidents are routed

When a rule, an alert source or a synthetic check leaves its escalation policy to the default (the default alias), routing places the incidents it opens: When a source chooses a policy of its own, or no escalation, that choice stands and routing only picks the team.

​
Routing order

When an incident opens, routing looks at: The team and the escalation policy are decided apart:
  • The team is the first one found: the matched rule’s team, the service’s owning team, the team the label points to.
  • The escalation policy is the matched rule’s policy. When the rule sends to a team, or no rule matches, it is that team’s on-call policy; with no on-call policy or no team, it is the default policy.
The service name is the label service.name, else service, else the incident’s first affected service; the namespace is the label service.namespace, or default without it. The result is written on the incident when it opens; later changes to routing leave open incidents as they are.

​
Routing rules

Routing rules lists the rules in the order they are tried, each row with its conditions, minimum severity, origins and target. Drag a row, or press ↑ ↓ on the handle at its start, to change the order; the new order is saved at once. The switch at the end of a row turns the rule off or on. When the team or policy a rule sends to is deleted, its row shows Target deleted and the rule is skipped.

​
Create a rule

  1. Click New rule and enter a Name.
  2. Under Conditions, click Add condition and enter a label, a comparison and a value. A rule matches when all its conditions hold; without conditions it matches every incident.
  3. Under Scope, optionally set:
    • a Minimum severity;
    • the Origins the rule applies to: Alert rules, External alerts, Synthetic checks, Hand-made incidents. With none selected, incidents from every origin are compared;
    • the Priority: only incidents of the ticked priorities match, and an incident without a priority never does; with none ticked, priority does not matter;
    • the Time: Any time, Only inside these hours, or Only outside these hours. The hours are weekly ranges in one timezone, each with its days and an HH:MM start and end, judged at the moment the incident opens. Under Holidays, the hours can leave the days off of a holiday calendar out, or apply on them only. For example, the same labels go to the developers’ team in working hours and to the on-call team otherwise, holidays included.
  4. Under Send to, choose:
  5. Click Create. A new rule goes last.
An organization has at most 200 routing rules, a rule at most 16 conditions, and a condition at most 100 values.

​
Team on-call policies

Team on-call policies lists the organization’s teams with their member counts and owned services. The service count links to the service catalog filtered to the team, where a service’s owning team is also registered. With an escalation policy chosen for a team, incidents routed to the team escalate by it; None, default policy leaves them to the default policy. Teams are managed under Identity & Access → Teams.

​
Try it

Try it works out how a set of labels would be routed by the current rules and teams:
  1. Under Labels, enter one key=value per line, such as service.name=checkout.
  2. Choose the Origin, the Severity, and the Priority. To try rules with a time, choose a moment in Opens at; empty is now.
  3. Click Try.
The result shows the team, the escalation policy and the reason, and what each of the four steps saw: which rule matched, which team owns the service, which team the label points to, and whether the default policy was needed.

​
Routing on incidents

The Assignees part of an incident’s details shows the team it was routed to and why, such as Matched rule “Payments in production” or Owner of service checkout. The incident list shows the team under the owner; when the current user belongs to a team, the list gains My teams, which lists the incidents routed to those teams. Alert notification events carry the routed team. A notify policy whose recipients are Team members or Team lead without a team set notifies that team.

​
Import and export

Import/export above the routing rules moves them between organizations as a file:
  • Export all routing rules downloads a molesignal.routing-rules/v1 bundle; with rules selected, only those. Escalation policies, teams, and holiday calendars are named by name.
  • Import routing rules… takes a bundle as JSON or YAML, tries it first, and lists what is created, updated, unchanged, or wrong. Rules are matched by name, and nothing is written while any rule is wrong. The rules of the file go first, in the file’s order; the other rules keep their order after them.
Importing requires alerts.routing.manage. Escalation policies and on-call schedules have the same; see Import and export.

​
Cross-cluster federation

With cross-cluster federation on, routing rules and team on-call policies are not synchronized between clusters, because teams and the APM service catalog belong to each cluster. Escalation policies are synchronized, so a rule that sends to a policy works on every cluster; each cluster’s routing is set up on that cluster.

​
API

Last modified on October 31, 2026