Using Tera templates in routing rule conditions
A routing rule condition is a Tera expression that must evaluate to true or false.
The system automatically wraps your input with {{ }}, so you only need to provide the expression itself.
This expression evaluates to true when the alert name starts with "CPU".
Alerts
Condition for alert name starting with certain text
| Alert name | Result |
|---|---|
| CPU usage high | true |
| CPU saturation | true |
| Memory usage high | false |
Condition for alert name containing certain text
| Alert name | Result |
|---|---|
| CPU usage high | true |
| Database CPU spike | true |
| Memory usage high | false |
Condition for alert name matching a regex
^cpumatches alert names starting with "cpu"(?i)makes the match case-insensitive
| Alert name | Result |
|---|---|
| CPU usage high | true |
| cpu saturation | true |
| Memory usage high | false |
Condition for alert containing a specific label
| Labels | Result |
|---|---|
group: payments | true |
| label not present | false |
This condition is useful when routing alerts based on ownership labels such as team, group, or service.
Condition for alert containing a specific value for a label
| Environment label | Result |
|---|---|
| production | true |
| staging | false |
Use this rule to route production alerts separately from staging or development alerts.
Cases
Routing rules can also evaluate properties from the Cases payload when the entity type is cases.
Cases represent incidents created from alerts and move through lifecycle states such as OPEN, ACKNOWLEDGED, or CLOSED. The payload is accessible through the case object.
Condition for case status
Route notifications only when a case is open.
| Case status | Result |
|---|---|
| OPEN | true |
| CLOSED | false |
Typical use: send notifications only when a case is created or active.
Condition for acknowledged cases
Send notifications only when a case has been acknowledged.
| Case status | Result |
|---|---|
| ACKNOWLEDGED | true |
| OPEN | false |
Typical use: notify stakeholders when an incident has been acknowledged by an engineer.
Combine case conditions
Route notifications only for acknowledged critical cases.
| Status | Severity | Result |
|---|---|---|
| ACKNOWLEDGED | critical | true |
| ACKNOWLEDGED | warning | false |
| OPEN | critical | false |
Typical use: escalate acknowledged critical incidents.
Entity-type specific routing
Routing rules may process events from different entity types such as alerts or cases. Check the entity type using the _context.entityType field.
Route only case events
| Entity type | Result |
|---|---|
| cases | true |
| alerts | false |
This condition ensures the routing rule only applies to case notifications.
Route alerts but ignore cases
Use this when a routing rule should apply only to alert notifications.
How conditions differ from other templates
Boolean only
Regular templates render text, while routing rule conditions must return a boolean value (true or false).
Invalid:
Valid:
Do not include {{ }}
The system automatically wraps your expression.
Incorrect:
Correct:
Missing variables evaluate to false
If a referenced variable does not exist in the payload, the condition evaluates to false.
If the team label is missing, the condition returns false. To avoid ambiguity, explicitly check that the field exists:
Syntax quick start
Comparisons
==, !=, >, >=, <, <=
Logic
and, or, not