Monitors

Any query can become an alert. Three evaluation strategies, one routing model.

A monitor runs an LSQL query on a schedule and compares the result to a condition. When the condition holds it notifies; when it stops holding it resolves. That is the whole model.

Three types

Threshold

Fires when a number crosses a line you set.

Anomaly

Fires when a number leaves its own baseline.

Anatomy of a monitor

Field	Does
`apl`	The query. Must return one numeric column, usually binned over time
`interval_minutes`	How often it runs. Minimum 1
`range_minutes`	How far back each run looks
`operator` + `threshold`	The condition, for threshold monitors
`notifiers`	Where it goes when it fires
`resolve_after_minutes`	Consecutive healthy minutes before auto-resolving
`muted_until`	Suppress notification without stopping evaluation

States

State	Means	Notifies?
`ok`	Condition not met	On the transition out of `alert`
`alert`	Condition met	On the transition into `alert`
`no_data`	The query returned no rows	Configurable — off by default

no_data is the state that bites

A service that stops sending logs entirely produces no rows, so an error-rate monitor reads no_data, not alert. Total failure looks identical to perfect health. Set notify_on_no_data: true on anything that matters.

Monitors people do not mute

Alert on symptoms your users feel, not on causes. High CPU is not an incident; failed checkouts are.
Bin to the evaluation interval. A 1-minute bin checked every 5 minutes fires on the worst minute.
Add a floor: | where requests > 100. Two errors out of three requests at 4am is 66% and means nothing.
Put the runbook in the name. Checkout 5xx > 25/5m — see runbook/checkout reads well on a pager.

PreviousDashboards as code NextThreshold monitors