> ## Documentation Index > Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt > Use this file to discover all available pages before exploring further. # Alert routing > Send new incidents to the right team and escalation policy by routing rules, the service's owning team or the team label, and try how a set of labels would be routed. Routing decides which team a new incident goes to and which [escalation policy](https://docs.molesignal.com/en-US/alerting/on-call.md#escalation-policies) 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](https://docs.molesignal.com/en-US/alerting/rules.md), an [alert source](https://docs.molesignal.com/en-US/alerting/sources.md) or a [synthetic check](https://docs.molesignal.com/en-US/synthetics.md#alert-incidents) leaves its escalation policy to the default (the `default` alias), routing places the incidents it opens: | Source | Routed when | | - | - | | Rule | It names no `escalation_policy_id`. Every rule saved in the rule workbench does so. | | Alert source | Its **Escalation policy** is **Routed (default)**, which a new source starts with. | | Synthetic check | Its **Escalation policy** is **Routed**. | | Incident opened by hand | **Who takes it** is **Route it**; see [Open an incident by hand](https://docs.molesignal.com/en-US/alerting/incidents.md#open-an-incident-by-hand). | 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: | Order | Basis | Details | | - | - | - | | 1 | Routing rules | Tried from the top; the first rule that matches decides. | | 2 | Service owner | The **Owning team** registered for the incident's service in the [APM service catalog](https://docs.molesignal.com/en-US/apm#service-catalog). Archived services do not count. | | 3 | Team label | The label `team_id` holding a team ID, or the label `team` holding a team name (case-insensitive). When more than one team has that name, the name names no team. | | 4 | Default policy | The policy named `default`; see [The default policy](https://docs.molesignal.com/en-US/alerting/on-call.md#the-default-policy). | 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. | Comparison | Matches when | | - | - | | **equals** | The label equals the value. | | **does not equal** | The label differs from the value, or the incident lacks the label. | | **is one of** | The label equals any of the values, separated by commas. | | **matches regex** | The whole label value matches the regular expression. | 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](https://docs.molesignal.com/en-US/alerting/on-call.md#holiday-calendars) 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: | Target | Effect | | - | - | | **Team** | The incident goes to the team and escalates by its on-call policy, or by the default policy when the team has none. | | **Escalation policy** | The incident takes this policy; the team still comes from the service owner or the team label. | 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](https://docs.molesignal.com/en-US/identity/teams.md#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](https://docs.molesignal.com/en-US/notification-channels#create-templates-and-policies) 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](https://docs.molesignal.com/en-US/alerting/on-call.md#import-and-export). ## Cross-cluster federation With [cross-cluster federation](https://docs.molesignal.com/en-US/settings/data-plane.md#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 | Action | Endpoint | | - | - | | List routing rules | [`GET /api/v1/alerts/routing/rules`](https://docs.molesignal.com/en-US/api/alerting/list-routing-rules) | | Create a routing rule | [`POST /api/v1/alerts/routing/rules`](https://docs.molesignal.com/en-US/api/alerting/create-routing-rule) | | Update a routing rule | [`PUT /api/v1/alerts/routing/rules/{id}`](https://docs.molesignal.com/en-US/api/alerting/update-routing-rule) | | Delete a routing rule | [`DELETE /api/v1/alerts/routing/rules/{id}`](https://docs.molesignal.com/en-US/api/alerting/delete-routing-rule) | | Reorder | [`PUT /api/v1/alerts/routing/rules/order`](https://docs.molesignal.com/en-US/api/alerting/reorder-routing-rules) | | List team on-call policies | [`GET /api/v1/alerts/routing/teams`](https://docs.molesignal.com/en-US/api/alerting/list-routing-teams) | | Set a team on-call policy | [`PUT /api/v1/alerts/routing/teams/{team_id}`](https://docs.molesignal.com/en-US/api/alerting/set-team-policy) | | Try routing | [`POST /api/v1/alerts/routing/test`](https://docs.molesignal.com/en-US/api/alerting/test-routing) | | Import and export | [`GET /api/v1/alerts/routing/rules/export`, `POST /api/v1/alerts/routing/rules/import`](https://docs.molesignal.com/en-US/api/alerting/oncall-transfer) | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.