> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Alert Routing
> Use Alert Routes to determine which teams, services, and escalation policies receive incoming alerts from your monitoring tools based on conditions you define.
## Overview
Alert Routing ensures that alerts from your monitoring and observability systems reach the correct responders quickly and reliably. Rootly provides a unified routing layer that works across all alert sources, enabling consistent on-call workflows.
Rootly supports two routing pathways:
1. **Routing inside your monitoring tool** (Datadog, PagerDuty, Opsgenie, etc.)
2. **Routing inside Rootly** using centralized **Alert Routes**
This guide focuses on routing **inside Rootly**.
***
## What Is an Alert Route?
An **Alert Route** defines *when*, *how*, and *to whom* Rootly should send alerts. It supports evaluation against:
* Alert Sources
* Alert Fields (normalized metadata)
* Raw payload values (JSONPath)
* Teams, services, and escalation policies
**Tip:** Alert Routes work best when combined with **Alert Fields**, which let you write stable routing logic even when payload schemas vary across providers.
***
## Creating an Alert Route
Navigate to **Alerts → Routes** and click **New Route**, then configure the following:
Give the route a descriptive title that clarifies its purpose.
Select one or more alert sources the route should evaluate. Sources can be added or removed at any time.
A route can only evaluate sources that already exist, so connect the tool first — see [Alert Sources](/alerts/alert-sources) for how to connect one and what to configure on it, or the [integrations catalog](/integrations/overview) for per-vendor setup.
The owning team controls who can edit the route.
**Permissions:**
* Team Admins may only create routes **for their own team**.
* Teams can only route alerts **from alert sources they own**.
After creating a route, you can begin adding Routing Rules.
***
## Configuring Routing Rules
Routing Rules determine *which alerts should page responders* and *where they should go*.
Click **Add routing rule** to create one.
***
## Routing Rule Conditions
Conditions define when a rule should trigger.
### Select a Field
You may reference:
* **Alert Fields** (recommended)
* **Payload values via JSONPath**
Alert Fields ensure your routing logic remains stable even if payload structures change.
### Choose an Operator
Supported operators include:
* *is one of*
* *contains*
* *starts with*
* *matches regex*
* *is empty*
* and more
Use **regex** when values vary across alert providers and need flexible matching.
### Add Additional Conditions
Use **AND/OR** groups to define complex routing logic.
### Live Preview
Rootly shows matching historical alerts to validate your logic.
***
## Routing Rule Destinations
Each rule must specify **who receives the alert**. Rules can target any of three destination types, and a single rule may include multiple destinations — all are paged when it fires.
Pages the team's configured escalation policy. Recommended for easier reporting and maintenance.
Pages the service's configured escalation policy. Recommended alongside teams.
Page a policy directly. Works, but is harder to report on than routing through a team or service.
Routing to a team or service automatically triggers its configured escalation policy.
For easier reporting and maintenance, Rootly recommends routing to **teams** or **services**, not directly to escalation policies.
Rules may include **multiple destinations**, all of which will be paged when the rule fires.
***
## Completing the Alert Route
A route may contain up to 200 rules — see [Limits](#limits).
Rootly evaluates rules **top-to-bottom**, so ordering matters.
Use the rule menu (**… → Reorder rule**) to adjust order.
***
## How Rootly Routes Alerts
Rootly evaluates alerts in two sequential stages.
### Stage 1 — Payload-Based Routing
If the alert payload contains a **target ID** (team or service), Rootly immediately routes the alert there without evaluating Alert Routes.
### Stage 2 — Evaluate Alert Routes
If the alert does not specify a target:
### Evaluate Routes
Rootly evaluates **every Alert Route associated with the alert’s source**.
### Evaluate Rules
Within each route, rules are evaluated **from top to bottom**.
* The first matching rule triggers paging
* Rootly stops evaluating additional rules in that route
* Other routes referencing the same source will still run
If no rules match, the alert becomes a **Non-Paging Alert**. Review these in the Alerts dashboard by filtering **Status → Non-Paging**.
Order rules **most specific → least specific** to avoid unintended matches.
***
## Limits
| Limit | Maximum |
| - | - |
| Alert Routes per alert source | 100 |
| Routing rules per Alert Route | 200 |
Both limits are generous enough that most organizations never approach them. If you are near one, the remedy differs by which:
**Near 200 rules on a route.** Look for rules that differ only in the value they match. A single rule matching a field against several allowed values does the work of several one-value rules. Combine only where the merged rules page the same destinations — since only the first matching rule pages, merging rules with different targets changes behavior rather than preserving it.
**Near 100 routes on a source.** Combining rules does not help here, because the count is of routes. Look instead for routes that page the same destination under different conditions, and fold those conditions into one route's rule list.
***
## Alert Timeline
Every routed alert includes a timeline event documenting:
* Which **Alert Route** was applied
* Which **Routing Rule** matched
* Which **destinations** were paged
This ensures responders understand *why* they were paged.
***
## Handling Alert Storms
When an incident produces a flood of alerts, the goal is usually not "silence everything" — it's "reduce paging noise without losing the record of what fired." Rootly gives you four levers for that; picking the right one depends on whether the storm is predictable and how much visibility you want to keep.
| Lever | What It Does | Reach for It When |
| - | - | - |
| [Alert Grouping](/alerts/alert-grouping) | The first matching alert pages; later matches join silently under the same leader. | Multiple monitors firing on one underlying condition, especially at High urgency where you still want a page. |
| [Deferral Paths](/on-call/escalation-policies#deferral-paths) | Holds paging until a defined time window closes, then evaluates the escalation path. | Storms that land in predictable windows (weekends, overnight), or low-urgency traffic you want to batch. |
| [Default Alerts Channel](/integrations/slack/slack#smart-defaults) (Slack integration setting) | Announces every new alert to a single Slack channel as it arrives, independently of routing. | You want continuous Slack visibility of alerts even when they aren't paging anyone. |
| Disabling a route or its rules | Stops the route (or specific rule) from matching until you re-enable it. Other routes on the same source still evaluate; alerts that no route matches become **Non-Paging Alerts**. | Emergency silence during a storm you can't predict, when nobody should be paged for that source *and* no other route is picking it up. |
**Disabling a route silences the Slack destinations attached to its escalation policy.** Slack channel targets sit inside escalation policy levels, and those only run once a routing rule has matched. Switch the route off and nothing matches, so no page and no Slack message from that path go out. If you want the "silence paging but keep Slack visibility" combination, turn on the **Default Alerts Channel** setting in your Slack integration first, then disable the route — the Default Alerts Channel fires on alert creation, before any routing rule runs, so it survives the route being off.
Other Slack automation stays active regardless: **team or service alert broadcasts** and **alert workflows** are independent of routing and continue to fire when a route is disabled. If none of those are configured, the alert only appears in the Alerts list in the web app.
Disabled routes stay off until someone manually re-enables them, so this is a deliberate lever, not a scheduled one. For scheduled batching, use a Deferral Path.
***
## Best Practices
* Prefer **Alert Fields** over JSONPath for stability.
* Start with broad routing categories and refine with specific rules.
* Keep rule names action-oriented and descriptive.
* Regularly check **Non-Paging Alerts** for routing gaps.
* Route to **teams/services**, not escalation policies, for better ownership.
* Combine routes thoughtfully when different teams own different tools.
***
## Troubleshooting
* Ensure the alert source is included in at least one route.
* Verify that at least one rule matches the alert.
* Confirm the alert payload does not contain a `target_id`, which overrides routing.
* Check the rule order; a broader rule may be matching first.
* Validate operators and values used in conditions.
* Ensure Alert Field mappings are extracting values correctly.
* All routes referencing the alert source are evaluated.
* Remove unnecessary alert sources from routes.
* Tighten condition logic.
* Review the alert payload preview (purple pill tokens).
* Confirm your JSONPath reflects the actual alert structure.
* Use Alert Fields whenever possible.
***
## Related Pages
The umbrella page covering programmatic alert ingestion, sources, and noise reduction.
Connect monitoring tools — sources are what Alert Routes evaluate.
Recommended condition source for stable routing logic across payload changes.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.