How alerting works

How Alerting is organised

1 · ALERT — machine Detected by the engine DOWN PARTIAL kept for the plan’s retention, even with no channel attached

2 · INCIDENT — human What you communicate severity · status · updates published on the status page created from an alert in one click

3 · ESCALATION Who, in what order 1 · now→ Slack 2 · +10 min→ PagerDuty 3 · +30 min→ Email until someone acknowledges

4 · CHANNELS Slack Email PagerDuty Webhook +14 more

Dashboard › Alerting: Alerts (history, acknowledge, CSV) · Incidents · Escalation · Channels · Maintenance One rule: a piece of information lives in one place. The bell in the top bar carries product notifications only, never monitoring alerts. The org status pill in the top bar and the “Alerts” badge in the sidebar are the permanent signals.

The Alerting section of the dashboard is built around five objects, each with its own page — and one rule: a piece of information lives in exactly one place.

Page	What it holds
Alerts	Every event the engine detected — down, partial outage, degraded, recovered, SSL expiry — notified or not.
Incidents	What you declare and communicate: severity, status, updates, publication on the status page.
Escalation	Who gets notified, in what order, after how long without an acknowledgement.
Channels	The destinations: Slack, email, PagerDuty, webhooks… (eighteen of them, see below).
Maintenance	Planned windows that silence alerts for the monitors they cover.

A sixth page, Visitor reports, holds what the visitors of your status pages flagged themselves — see Alerts from a status page.

The bell in the top bar is a to-do list, not a log: it shows what needs attention right now — monitors that are down, ongoing incidents, maintenance in progress — plus the new visitor reports, and each entry disappears when its cause does. The permanent monitoring signal is the status pill in the top bar and the Alerts badge in the sidebar; the history is the Alerts log.

From a failed check to a notified human

1. Detection — an agent’s check fails. The engine applies the retry window and, for multi-region monitors, the majority rule (see Status & uptime). Only a confirmed state change raises an alert.
2. Alert — one row in the Alerts log: what, when, which monitor, with the evidence. Acknowledging it there is what “someone is on it” means to OKStatus.
3. Notification — the alert is pushed to every channel attached to the monitor, filtered by the alert kinds each channel accepts. What was sent, and whether it was delivered, is stored on the alert.
4. Escalation — an escalation policy (one on Free and Pro, unlimited on Max and Enterprise) keeps going after level 1: more channels after N minutes without acknowledgement, optionally repeated, until someone acknowledges.
5. Communication — you decide what the outside world sees: an incident on the status page, a scheduled maintenance window that silences alerts ahead of planned work, and subscriber emails that go out on their own.

What silences what

Situation	Alerts raised?	Channels called?	Status page
Monitor paused	No — no checks run	No	Shown as paused
Monitor muted	Yes, logged	No	Real status
Inside a maintenance window	No	No	“Under maintenance”
Alert acknowledged	Already raised	Escalation stops; recovery still sent	Unchanged
No channel attached	Yes, with a “no channel” badge	Nothing to call	Unchanged