Alerts are threshold rules checked continuously against a rolling window of
your traffic. When a metric crosses its threshold, the rule starts firing
and sends an email. When it recovers, the rule returns to ok and sends a
resolve email. A rule that keeps firing re-notifies on a cooldown.
Parts of a rule
Metrics
Existing rules that use a legacy metric continue to run and can still be
edited. New rules offer the four metrics above.
How checking works
A background job sweeps every enabled rule on an interval
(ALERT_EVAL_INTERVAL_MS, default 60 seconds). For each rule it computes the
metric over the window and compares it to the threshold:
- ok to firing: threshold crossed. Records a
fired event with the
observed value and threshold, and sends an email.
- firing to ok: metric recovered. Records a
resolved event and sends an
email.
- still firing: re-notifies at most once per
ALERT_RENOTIFY_MS (default
1 hour), so you aren’t emailed every minute.
Each transition is stored as an alert event, so every rule has a history of
when it fired and resolved.
Alert emails require email to be set up on the deployment
(RESEND_API_KEY). Without it, rules still run and change state, but no
emails are sent. See
self-hosting configuration.
List view
The Alerts page lists every rule with its metric, condition, current value,
lookback, last evaluation, and most recent firing. A small red marker appears
beside the name only while an enabled rule is firing. Select Edit to change
the rule and review its recent fired and resolved history. Plans cap how many
rules an organization can create; the
Usage panel shows your count against the limit.