# Condition templating

Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Fnotification-center%2Frouting%2Fcondition-templating.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Fnotification-center%2Frouting%2Fcondition-templating.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

## Use Tera templates in routing rule conditions[​](#use-tera-templates-in-routing-rule-conditions "Direct link to Use 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 provide only the expression itself.

```
alertDef.name is starting_with("CPU")
```

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

## Alerts[​](#alerts "Direct link to Alerts")

### Condition for alert name starting with certain text[​](#condition-for-alert-name-starting-with-certain-text "Direct link to Condition for alert name starting with certain text")

```
alertDef.name is starting_with("CPU")
```

| Alert name        | Result |
| ----------------- | ------ |
| CPU usage high    | true   |
| CPU saturation    | true   |
| Memory usage high | false  |

### Condition for alert name containing certain text[​](#condition-for-alert-name-containing-certain-text "Direct link to Condition for alert name containing certain text")

```
alertDef.name is containing("CPU")
```

| Alert name         | Result |
| ------------------ | ------ |
| CPU usage high     | true   |
| Database CPU spike | true   |
| Memory usage high  | false  |

### Condition for alert name matching a regex[​](#condition-for-alert-name-matching-a-regex "Direct link to 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 name        | Result |
| ----------------- | ------ |
| CPU usage high    | true   |
| cpu saturation    | true   |
| Memory usage high | false  |

### Condition for alert containing a specific label[​](#condition-for-alert-containing-a-specific-label "Direct link to Condition for alert containing a specific label")

```
alertDef.entityLabels.group is defined
```

| 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[​](#condition-for-alert-containing-a-specific-value-for-a-label "Direct link to Condition for alert containing a specific value for a label")

```
alertDef.entityLabels.environment == "production"
```

| Environment label | Result |
| ----------------- | ------ |
| production        | true   |
| staging           | false  |

Use this rule to route production alerts separately from staging or development alerts.

## Cases[​](#cases "Direct link to 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[​](#condition-for-case-status "Direct link to Condition for case status")

Route notifications only when a case is open.

```
case.status == "OPEN"
```

| Case status | Result |
| ----------- | ------ |
| OPEN        | true   |
| CLOSED      | false  |

Typical use: send notifications only when a case is created or active.

### Condition for acknowledged cases[​](#condition-for-acknowledged-cases "Direct link to Condition for acknowledged cases")

Send notifications only when a case has been acknowledged.

```
case.status == "ACKNOWLEDGED"
```

| Case status  | Result |
| ------------ | ------ |
| ACKNOWLEDGED | true   |
| OPEN         | false  |

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

### Combine case conditions[​](#combine-case-conditions "Direct link to Combine case conditions")

Route notifications only for acknowledged critical cases.

```
case.status == "ACKNOWLEDGED"

and case.severity == "critical"
```

| Status       | Severity | Result |
| ------------ | -------- | ------ |
| ACKNOWLEDGED | critical | true   |
| ACKNOWLEDGED | warning  | false  |
| OPEN         | critical | false  |

Typical use: escalate acknowledged critical incidents.

## Entity-type specific routing[​](#entity-type-specific-routing "Direct link to 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[​](#route-only-case-events "Direct link to Route only case events")

```
_context.entityType == "cases"
```

| Entity type | Result |
| ----------- | ------ |
| cases       | true   |
| alerts      | false  |

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

### Route alerts but ignore cases[​](#route-alerts-but-ignore-cases "Direct link to 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[​](#how-conditions-differ-from-other-templates "Direct link to How conditions differ from other templates")

### Boolean only[​](#boolean-only "Direct link to 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 {{}}[​](#do-not-include- "Direct link to 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[​](#missing-variables-evaluate-to-false "Direct link to 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[​](#syntax-quick-start "Direct link to Syntax quick start")

### Comparisons[​](#comparisons "Direct link to Comparisons")

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

Use `==` and `!=` with any value type. Use `>`, `>=`, `<`, and `<=` only on numeric fields: `case.priority` and `alertDef.priority` are strings (`"P1"` through `"P5"`), so compare them with `==` or `!=`.

String equality, for priorities, statuses, and labels:

```
case.priority == "P1"
```

Numeric comparison, for fields that hold a number:

```
alert.value > 80
```

### Logic[​](#logic "Direct link to Logic")

`and`, `or`, `not`

```
alertDef.priority == "P1" or alertDef.priority == "P2"
```

```
not alertDef.name is containing("test")
```

## Next steps[​](#next-steps "Direct link to Next steps")

Create and manage connectors that link Coralogix to third-party services in [Connectors](https://docs-docusaurus.kinsta.page/user-guides/notification-center/connectors/.md).