Routing Rules
Routing rules control how alert notifications are delivered to different destinations based on defined conditions. Each destination consists of a connector, a preset, and optional user-defined overrides. Rules can be applied sequentially or in parallel, depending on how you want the system to evaluate matches.
This is useful for routing alerts based on attributes like priority, source, or tags. For example, you might send P3 (warning) alerts to Slack and P1 (critical) alerts to PagerDuty.
Routing logic
Sequential routing
In sequential mode, the system evaluates routing rules one by one in order. When a rule matches, the notification is routed to its defined destinations, and evaluation stops. If no rules match, a fallback routing rule handles the notification.
Parallel routing
In parallel mode, all rules are evaluated simultaneously. Any rule that matches will be triggered, and the notification will be sent to all associated destinations. Rule order does not matter.
Set up routing
Step 1: Add a routing rule
Go to the Routing tab and click + Add routing rule.
Step 2: Define rule conditions
In the modal, configure the conditions that must be met for the rule to apply. When alerts are the notification source, conditions can be based on:
- Alert severity (e.g., P1, P3)
- Entity labels (e.g.,
service_name
) - Custom tags or other alert metadata
A full list of fields which may be used to build your routing rules for the the alerts entity type may be found here.
Dynamic templating examples can be found here.
Step 3: Set destinations
Choose one or more destinations for the alert. Each destination includes:
- A connector (e.g., Slack, PagerDuty)
- A preset configuration
- Optional overrides
Step 4: Save the rule
Click Create rule to add it to your routing configuration.
Example: Routing by alert priority and entity
Suppose you want to handle alerts differently based on priority and service label. You create three rules:
- Rule for P3 alerts → send to Slack
- Rule for P1 alerts → send to PagerDuty
- Rule for service
auth-service
→ send to Slack
Sample alert
Parallel routing behavior
All rules are evaluated:
- Rule 1 (P3): ❌ No match
- Rule 2 (P1): ✅ Match → Notification sent to PagerDuty
- Rule 3 (auth-service): ✅ Match → Notification sent to Slack
Result: Notification sent to both PagerDuty and Slack.
Sequential routing behavior
Rules are evaluated in order:
Example A
- Rule for P3: ❌ No match
- Rule for P1: ✅ → Notification sent to PagerDuty
- Rule for auth-service: 🚫 Not reached
Example B (different order)
- Rule for P1: ✅ → Notification sent to PagerDuty
- Rule for P3: 🚫 Not reached
- Rule for auth-service: 🚫 Not reached
Result: Notification sent to PagerDuty only.
Fallback routing rule
If no rules match an alert, a fallback routing rule ensures the notification is still delivered to a default destination. This prevents alert loss and ensures coverage for unexpected scenarios.
Manage routing rules
To edit or delete a rule:
- Hover over the rule in the Routing UI.
- Click the pencil icon to edit or the trash icon to delete.