Defining Routing Rules

Routing rules decide when to send notifications and where they go. Each rule evaluates notification data and, when it matches, sends the notification to one or more destinations.

How routing rules work

When a notification request matches a router, all of that router’s routing rules are evaluated in parallel.

Each rule contains a condition written in the Tera expression language.
Each rule can have one or more destinations.
If the condition evaluates to true, the notification is sent to all destinations defined in that rule.
If multiple rule conditions evaluate to true, the notification is sent to all destinations in all matching rules.

Rule components

Component	Purpose
Condition	Logical expression that must evaluate to `true` for the rule to trigger
Destinations	One or more connector–preset pairs that define where and how the notification is sent

Create a routing rule

Open a router from the Routers list.
Select + New rule.
Enter a name that reflects the rule’s purpose, such as Critical alerts or CPU warnings.
Define the condition, for example: alertDef.priority == "P1".
Select one or more destinations:
Choose a connector such as Slack, PagerDuty, or HTTPS.
Choose a preset, which defines the message structure.
Save the rule.

Condition syntax

Routing rule conditions use Tera expressions and must return true or false. Use logical operators and filters to build expressions.
Example Description
true Always applies 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.
alertDef.entityLabels.region == "EU" Routes alerts based on a specific entity label.

See the dynamic templating reference for more syntax examples:
https://coralogix.com/docs/user-guides/notification-center/dynamic-templating/

Rule evaluation behavior

Scenario	Result
Multiple rules evaluate to `true`	Notifications are sent to all destinations defined in those rules.
No rules evaluate to `true`	The router sends the notification to the fallback connector, if one is defined.
Condition fails due to a missing variable or error	The condition evaluates to `false`.

Example

Name	Condition	Destinations
Critical alerts	`alertDef.priority == "P1"`	PagerDuty, Slack (`#critical-alerts`)
Warnings	`alertDef.priority == "P3"`	Slack (`#warnings`)

Note: Use short, distinct rule names and narrow conditions to keep routing clear and predictable.

Next steps

Dynamic templating: Use Tera expressions to build powerful routing conditions
Routers: Refine router scopes and rule sets for teams, environments, or services
Connectors and presets: Attach the right destinations and message formats to each rule

Previous Create a Router

Next Connectors

Example	Description
`true`	Always applies 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`.
`alertDef.entityLabels.region == "EU"`	Routes alerts based on a specific entity label.