Routing Overview

Routing controls how notifications are delivered once a notification trigger event occurs. It connects notification sources such as alerts or cases to destinations based on labels and routing rules.

How routing works

Routing uses label-based logic to determine which destinations receive a notification.

1. An alert or case generates a notification request.
2. Notification Center matches the request’s labels against the routing labels defined in routers.
3. For each matched router, all routing rules are evaluated in parallel.
4. Every rule with a condition that evaluates to true sends the notification to its configured destinations.
5. If no rule matches, a fallback connector (if defined) handles delivery.

This separates alert logic (what triggers the alert) from delivery logic (where the notification goes), making routing easier to scale and maintain.

Routing components

Label-based routing

Routers match only when every label defined in the router is also present in the incoming notification. Extra labels in the notification do not affect the match.

The examples below show how router labels are compared with notification labels and whether a match occurs.

Router labels	Notification labels	Result
team:teamA, environment:prod	team:teamA, environment:prod	✅ Matched
team:teamA, environment:dev	team:teamA, environment:prod	❌ Not matched
environment:prod	team:teamA, environment:prod, service:app1	✅ Matched
team:teamA, environment:prod	team:teamA, environment:prod, service:app1	✅ Matched
team:teamA, environment:dev, service:app1	team:teamA, environment:prod, service:app1	❌ Not matched

Label-based routing lets each team, environment, or service manage notifications independently without duplicating configuration.

Routing evaluation flow

Flow summary

1. Notification Center checks all routers.
2. Only routers with matching routing labels are selected.
3. Each matching router evaluates all of its routing rules.
4. Every rule that returns true sends a notification to its configured destinations.

flowchart TB

    A["Notification Triggered"]
    B["Notification request generated"]
    C["Check all routers in Notification Center"]

    D["Does the router’s routing labels match the notification?<br/>(Every router label must be present in the notification)"]

    E1["Add router to matched routers"]
    E2["Ignore router"]

    F["For each matched router, evaluate all<br/>routing rules in parallel"]

    G["Does a routing rule evaluate to TRUE?"]

    H1["Send notification to the rule's<br/>configured destination<br/>(connector + preset)"]

    H2["Did the router define a fallback<br/>connector?"]

    I1["Send via fallback connector"]
    I2["Drop notification"]

    %% FLOW
    A --> B
    B --> C
    C --> D

    D -->|Yes| E1
    D -->|No| E2

    E1 --> F

    F --> G

    G -->|Yes| H1
    G -->|No| H2

    H2 -->|Yes| I1
    H2 -->|No| I2

Routing conditions

Routing rules use Tera expressions that evaluate to true or false.

Condition	Description
true	Always routes when the router matches.
alertDef.priority == "P1"	Routes only P1 alerts.
alertDef.name is starting_with("CPU")	Routes alerts where the name starts with “CPU”.

See Dynamic templating reference for full syntax.

Routing behavior

Routing behavior defines how Notification Center processes matches and rule evaluations.
Use these scenarios to understand how multiple routers and rules interact.

• Alert notification request 1: routing.team:teamA routing.environment:prod
  • Router 1: environment:prod → matched as routing label environment:prod is present in the notification request.
  • Router 2: team:teamA environment:prod  → matched as both routing labels environment:prod and team:teamA are present in the notification request.
• Alert notification request 2: routing.environment:prod
  • Router 1: environment:prod → matched as routing label environment:prod is present in the notification request.
  • Router 2: team:teamA environment:prod  → NOT matched as routing label team:teamA is not in the notification request.
• Alert notification request 3: routing.team:teamA ****routing.environment:prod routing.service:testApp
  • Router 1: team:teamA environment:prod  → matched as both routing labels environment:prod and team:teamA are present in the notification request.
  • Router 2: environment:prod  → matched as routing label environment:prod is present in the notification request.
  • Router 3: team:teamA environment:dev service:testApp   → NOT matched as routing label environment:dev is not in the notification request.

Next steps

• Add labels to alerts: Enable routers to match your notifications
• Routers: Learn how to create routers, rules, and fallbacks
• Routing rules: Design rule conditions and configure notification fan-out