Skip to content

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.

alertDef.name is starting_with("CPU")

This expression evaluates to true when the alert name starts with "CPU".

Alerts

Condition for alert name starting with certain text

alertDef.name is starting_with("CPU")
Alert nameResult
CPU usage hightrue
CPU saturationtrue
Memory usage highfalse

Condition for alert name containing certain text

alertDef.name is containing("CPU")
Alert nameResult
CPU usage hightrue
Database CPU spiketrue
Memory usage highfalse

Condition for alert name matching a regex

alertDef.name is matching("(?i)^cpu")
  • ^cpu matches alert names starting with "cpu"
  • (?i) makes the match case-insensitive
Alert nameResult
CPU usage hightrue
cpu saturationtrue
Memory usage highfalse

Condition for alert containing a specific label

alertDef.entityLabels.group is defined
LabelsResult
group: paymentstrue
label not presentfalse

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

alertDef.entityLabels.environment == "production"
Environment labelResult
productiontrue
stagingfalse

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 == "OPEN"
Case statusResult
OPENtrue
CLOSEDfalse

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 == "ACKNOWLEDGED"
Case statusResult
ACKNOWLEDGEDtrue
OPENfalse

Typical use: notify stakeholders when an incident has been acknowledged by an engineer.

Combine case conditions

Route notifications only for acknowledged critical cases.

case.status == "ACKNOWLEDGED"
and case.severity == "critical"
StatusSeverityResult
ACKNOWLEDGEDcriticaltrue
ACKNOWLEDGEDwarningfalse
OPENcriticalfalse

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

_context.entityType == "cases"
Entity typeResult
casestrue
alertsfalse

This condition ensures the routing rule only applies to case notifications.

Route alerts but ignore cases

_context.entityType == "alerts"

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:

"CPU alert"

Valid:

alertDef.name is containing("CPU")

Do not include {{ }}

The system automatically wraps your expression.

Incorrect:

{{ alertDef.name is containing("CPU") }}

Correct:

alertDef.name is containing("CPU")

Missing variables evaluate to false

If a referenced variable does not exist in the payload, the condition evaluates to false.

alertDef.entityLabels.team == "payments"

If the team label is missing, the condition returns false. To avoid ambiguity, explicitly check that the field exists:

alertDef.entityLabels.team is defined
and alertDef.entityLabels.team == "payments"

Syntax quick start

Comparisons

==, !=, >, >=, <, <=

case.priority >= 3

Logic

and, or, not

alertDef.priority == "P1" or alertDef.priority == "P2"
not alertDef.name is containing("test")

Next steps