Skip to main content
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.