Alert rules

The DSL for selecting monitors, composing conditions, and fanning out to channels.

Anatomy

Rule = monitor_selector × condition tree × channel_ids

monitor_selector — which monitors this rule cares about: all, ids: [...], or tags_any: [...].
condition — a tree of leaf conditions composed with all_of / any_of.
channel_ids — fan-out destinations.

Leaf conditions

Type	What it checks	Parameters
`status_is`	Monitor status flips to a value	`value` (e.g. `down`), `for_consecutive_checks`
`latency_exceeds`	Response time over threshold	`value_ms`
`ssl_expires_within`	Leaf cert `notAfter` within window	`days`
`heartbeat_missed_for`	No heartbeat seen	`minutes`

Compound conditions

{
  "all_of": [
    { "type": "status_is", "value": "down", "for_consecutive_checks": 3 },
    { "any_of": [
        { "type": "latency_exceeds", "value_ms": 2000 },
        { "type": "ssl_expires_within", "days": 7 }
    ]}
  ]
}

Max depth 3. The UI’s quick form only writes single-leaf rules; compounds are available via the alert-rule editor / API.

Dedup and cooldown

A rule that flaps doesn’t spam. The engine tracks the last fire per (rule, monitor) and won’t open a second incident while one is still active. After resolve, the next match opens a new incident.

Auto-resolve

auto_resolve_after_ok_checks (default 3) controls how many consecutive OK results auto-close the linked incident. Set higher for flappy targets; set to 0 to disable.

Severity → channel tone

Channels render tone based on severity:

P1 / status = down → danger
P2, P3, latency / ssl → warning
Resolve → success

This drives Slack attachment color, Discord embed color, Telegram badge prefix, and email subject prefix.

Maintenance respect

Rules respect maintenance windows by default. A monitor inside an active maintenance window won’t trigger alerts. Toggle per-rule via the rule editor → advanced.