How routing works
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.
- An alert or case generates a notification request.
- Notification Center matches the request's labels against the routing labels defined in routers.
- For each matched router, all routing rules are evaluated in parallel.
- Every rule with a condition that evaluates to
truesends the notification to its configured destinations. - If no rule matches, a fallback connector (if defined) handles delivery.
This separates entity logic (what triggers the notification) from delivery logic (where the notification goes), making routing easier to scale and maintain.
Routing components
| Component | Description |
|---|---|
| Router | Logical container for routing rules. A router matches incoming notifications using routing labels. |
| Routing label | Key-value pair that filters notifications, such as environment:prod. |
| Routing rule | Condition that determines which destinations receive the notification. |
| Destination | Connector-preset pair that defines where and how a notification is sent. |
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.
Dynamic routing labels
A router's label value can be a template rather than a fixed string, for example:
{{ groups.team | default(value="platform") }}
A router with one of these is a dynamic router. Its value is resolved when a notification fires, from the triggering group, so the router stands for every value that field can take rather than for one of them.
That changes what a match means. A router whose labels are all fixed either matches a notification or does not, and you can tell in advance. A dynamic router matches only when the notification resolves to that router's exact value, which is not known until the alert triggers.
| The router's labels | What it means |
|---|---|
| All fixed | The router matches, or it does not. Delivery is certain. |
| One or more dynamic | The router delivers only when the notification resolves to its value. |
| A dynamic label that falls back | The template's default value was used because the field was absent. |
Because every label on a router has to match, a single dynamic label is enough to make the whole router uncertain.
Where you see this
When you set routing labels on an alert, the wizard lists the routers your labels reach. Routers matched only through a dynamic label are grouped under Potential routers, and the wizard shows the value each one is waiting for. A router listed there is one that could receive the alert, not one that will.
A dynamic router also carries a note at the top of its card: This is a dynamic router, so notifications are only sent when specified parameters are met.
If an alert needs to reach a destination every time it fires, give the router a fixed label value, or add a custom notification on the alert itself, which delivers regardless of label matching.
Routing evaluation flow
Flow summary:
- Notification Center checks all routers.
- Only routers with matching routing labels are selected.
- Each matching router evaluates all of its routing rules.
- Every rule that returns
truesends a notification to its configured destinations.
- If no router matches, the notification is dropped.
- If a router matches but no rule conditions return
true, the notification is dropped unless a fallback connector is defined.
Routing conditions
Routing rules use Tera expressions that evaluate to true or false.
- Alert condition examples
- Case condition examples
| Condition | Description |
|---|---|
true | Always routes when the router matches. |
alert.highestPriority == "P1" | Routes only P1 alerts. |
alertDef.name is starting_with("CPU") | Routes alerts where the name starts with "CPU". |
| Condition | Description |
|---|---|
true | Always routes when the router matches. |
case.priority == "P1" | Routes only P1 Cases. |
case.status == "ACKNOWLEDGED" | Routes Cases that have been acknowledged. |
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:teamArouting.environment:prod- Router 1:
environment:prod: matched because routing labelenvironment:prodis present in the notification request. - Router 2:
team:teamAenvironment:prod: matched because both routing labelsenvironment:prodandteam:teamAare present in the notification request.
- Router 1:
- Alert notification request 2:
routing.environment:prod- Router 1:
environment:prod: matched because routing labelenvironment:prodis present in the notification request. - Router 2:
team:teamAenvironment:prod: NOT matched because routing labelteam:teamAis not in the notification request.
- Router 1:
- Alert notification request 3:
routing.team:teamArouting.environment:prodrouting.service:testApp- Router 1:
team:teamAenvironment:prod: matched because both routing labelsenvironment:prodandteam:teamAare present in the notification request. - Router 2:
environment:prod: matched because routing labelenvironment:prodis present in the notification request. - Router 3:
team:teamAenvironment:devservice:testApp: NOT matched because routing labelenvironment:devis not in the notification request.
- Router 1:
Case routing behavior
Cases use the same label-matching logic as alerts. When a Case lifecycle event occurs, Notification Center generates a notification that includes the Case's Ownership Tags (environment, service, and team). Routers match these tags in the same way they match alert routing labels.
- Case notification request 1:
team:sreenvironment:prod- Router 1:
team:sreenvironment:prod: matched because both routing labels are present. - Router 2:
environment:prod: matched because routing labelenvironment:prodis present.
- Router 1:
- Case notification request 2:
team:sreenvironment:prodservice:checkout- Router 1:
team:sreenvironment:prod: matched because both routing labels are present. - Router 2:
team:sreservice:checkout: NOT matched because routing labelenvironment:prodis missing from the router.
- Router 1:
Each matching router then evaluates its Cases routing rules separately from alert routing rules. This separation allows teams to manage incident lifecycle notifications independently from monitoring alert notifications.
View a router as code
Select View as code from a router's row actions or from the router editor to see its configuration as Terraform, Coralogix Operator YAML, or OpenAPI, then copy or download each format. The code is generated live from the backend, so the UI, API, and IaC definitions stay in sync. Available for saved routers other than the default router. Viewing requires the NOTIFICATION-CENTER-ROUTERS:READCONFIG permission. See View a connector as code for the full format reference.
Next steps
Configure routing labels on your alerts so routers can match them in Add routing labels to alerts.