Condition Logic

Build precise routing rules using AND/OR logic, label matching, time windows, and nested conditions.

How conditions work

A Condition node evaluates a rule against the current alert or incident. It has two outputs:

True — the rule matched; execution continues down this branch
False — the rule didn't match; execution continues down this branch (or stops if unconnected)

Each condition rule has three parts: field, operator, and value.

Available fields

Alert fields

Field	Type	Example values
`Severity`	enum	`critical`, `high`, `medium`, `low`, `info`
`Status`	enum	`firing`, `acknowledged`, `resolved`, `suppressed`
`Source`	string	`nagios`, `kaseya`, `custom-script`
`Title`	string	Any substring match
`Description`	string	Any substring match
`Integration ID`	string	UUID of the originating integration
`Client Name`	string	From the incident's client name
`Label`	key-value	Any label attached to the alert
`Dedup Count`	number	How many times this alert has deduplicated
`Flapping Count`	number	How many times severity has changed

Time-based fields

Field	Type	Example values
`Hour of day`	number	`0`–`23` (UTC)
`Day of week`	enum	`Monday`, `Tuesday`, …
`Is business hours`	boolean	`true`/`false` (uses org timezone)
`Is on-call`	boolean	Whether an on-call schedule has an active engineer

Operators

Operator	Applicable to	Notes
`equals`	enum, string	Exact match, case-insensitive
`not equals`	enum, string	Exact mismatch
`contains`	string	Substring match
`starts with`	string	Prefix match
`greater than`	number	Numeric comparison
`less than`	number	Numeric comparison
`in list`	enum	Matches any of a set of values
`not in list`	enum	Matches none of a set of values
`exists`	label	The label key is present
`not exists`	label	The label key is absent

AND / OR logic

By default, a Condition node evaluates a single rule. To combine multiple rules, click Add Rule in the Inspector and select the logic mode:

ALL (AND) — every rule must be true for the True branch to be taken
ANY (OR) — at least one rule must be true

Example — route only critical alerts from production:

ALL of:
  Severity = critical
  Label "env" = production

Example — notify for high or critical, but not during quiet hours:

ALL of:
  Severity in [critical, high]
  Is business hours = false

Nested conditions

You can nest conditions by connecting Condition nodes in sequence:

Trigger
  └─ Condition: Severity = critical
       True ─ Condition: Label "env" exists
                  True ─ Notify (with env label in message)
                  False ─ Notify (generic critical alert)
       False ─ (stop)

There's no hard limit on nesting depth up to the workflow step limit (50 nodes).

Label matching

Use the Label field to match on any key-value pair attached to an alert:

Label key:   "client"
Operator:    equals
Value:       "Acme Corp"

This is powerful for routing — send Acme Corp alerts to one Slack channel and Contoso alerts to another, all in one workflow.

Time-based routing

Route by hour of day:

Hour of day >= 18   → escalate to on-call (after-hours)
Hour of day < 8     → escalate to on-call (after-hours)

Business hours vs. after-hours:

Is business hours = true  → Slack notification only
Is business hours = false → Slack + SMS to on-call

Business hours are defined per organization in Settings → General → Business Hours.

Common patterns

Skip noisy integrations

Source != "flapping-monitor"
→ Continue

Client-based routing

Label "client" = "Acme Corp"
→ Notify: #acme-alerts Slack channel

Label "client" = "Contoso"
→ Notify: #contoso-alerts Slack channel

Severity tier escalation

Severity = critical → Immediate SMS + voice call
Severity = high     → Slack + email
Severity = medium   → Slack only
Severity = low      → Email only
Severity = info     → (no action)

Suppress flapping alerts

Flapping Count >= 3 → Suppress automatically

Builder Tutorial Escalation Patterns