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

Choose between sequential or parallel routing for your notifications. If no rules match, a fallback routing rule handles the notification.

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.

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

{
  "name": "Sample alert",
  "priority": "P1",
  "entityLabels": {
    "service_name": "auth-service"
  }
}

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.

Managing Existing Presets

Next Dynamic Templating