Alert rules (threshold & spike)
Fire when the error rate crosses a number you set, or spikes above the usual — by email, webhook or status page.
Every plan emails you when a new incident appears or a resolved one regresses (see Incident feed → Email alerts). Alert rules go further: they watch the rate of errors and tell you when something unusual is happening, even when no single incident is new — a deploy that doubles your error rate, a payment provider that starts failing for everyone at once.
Alert rules are included on Pro and above. Set them up under Settings → Alerts.
Two kinds of rule
Threshold — at least N in the last W minutes. "100 or more errors in 5 minutes." Predictable, and right for things you know the normal level of.
Spike — at least X× the usual, and at least N. "3× the usual errors in 15 minutes, at least 20." The usual level is the average for a window of that size over the trailing 24 hours, so the rule adapts to your traffic: a site that normally sees 5 errors every 15 minutes fires at 20; a site that sees 200 fires at 600. The "at least N" floor stops a quiet site from paging you when 1 becomes 3.
Each rule counts one of:
- errors — every report;
- distinct incidents — how many different problems, not how many occurrences;
- affected users — distinct visitors who hit an error.
Optionally only for one error type (server errors, network failures, JavaScript crashes…), and for windows of 5, 15 or 60 minutes.
When a rule fires
Rules are checked every minute. A rule fires once when its condition becomes true, stays firing while it holds, and recovers when it clears — one notification each way, so a condition that holds for an hour sends two emails, not sixty. After it recovers, the rule won't fire again inside its cooldown (default an hour), so a metric hovering around the line doesn't flap.
While a rule is firing, the Overview shows it, and the Alerts page lists every firing with its peak value and how long it lasted.
Where it notifies
- Email — the organization owner and admins (each can switch incident alerts off on their profile), plus up to ten extra addresses on the rule: an on-call inbox, a pager-to-email bridge.
- Webhooks (Business) — every endpoint subscribed to
alert.triggered/alert.resolvedreceives the rule name, condition, value, limit, baseline and a link. Slack-format endpoints get a readable message; JSON-format endpoints (Zendesk, PagerDuty's email/webhook integrations, your own services) get the signed envelope described in Webhooks. - Status page — a rule can post to your public status page while it fires ("We're investigating elevated errors") and close the notice when it recovers, so your customers hear from you before they write in.
Recommended starting point
Add recommended rules creates two: Error spike (3× the usual in 15 minutes, at least 20) and Error flood (100 or more in 5 minutes). Adjust the numbers once you have a week of data; the Alerts page shows what each rule would have measured.