Alerts
Alerts open from observed monitor failures. Notifications fan out when configured — open count is real, not a decorative zero.
Overview#
After a check runs, evaluation rules decide whether to open, touch, or resolve an alert for that monitor kind (HTTP 5xx / timeout / network, SSL expiry, missing DNS records, and related cases). Alerts are an ops signal on top of checks — not a second probe engine.
Set up, step by step#
Step 1: Create a monitor with email alerts
Follow Monitoring setup. The create form explains that outage and recovery emails go to every verified workspace member. There is no separate per-monitor email toggle yet.
Step 2: Add delivery channels (Pro)
For Slack, Discord, Teams, or webhooks, configure channels under Notifications setup (Settings → Integrations).
Step 3: Verify on a real failure
After a check fails (wrong status, timeout, or network error), an alert opens. Acknowledge or resolve it in the product; recovery on a later successful check can also resolve. Empty open lists mean quiet or no runs — not simulated green.
Lifecycle#
- Open — failure matches an alert rule; at most one active alert per continuing failure window (touches do not re-notify).
- Acknowledge / resolve — operators can clear open alerts in the product; recovery on a later successful check can also resolve.
- Incidents — Pro can escalate into the incident desk; monitoring alerts and incidents are related but not identical.
Notifications#
Opened alerts can notify via email (and other channels when integrations are configured). Delivery is idempotent per alert recipient — retries use Trigger-backed notification workers. See Notifications.
Plans#
Alerting and email notifications are included on Free and Pro. Slack, Teams, Discord, and webhook channels require Pro. Continuous check → alert flow still depends on Trigger workers for scheduling and retries.
On Free, outage, recovery, SSL expiry (14, 7 and 1 days) and certificate-problem emails come from the daily checks on your one HTTP monitor and share a limit of 5 per hour and 20 per day. DNS change emails are off by default; turn them on from the monitor’s page. Changes always appear in the panel and the Impact timeline.
Limitations
- Resolved alert history in the project UI is incomplete (honest empty copy) — do not expect a full archive yet.
- Native PagerDuty / Opsgenie rotations are not first-class; use webhooks where available.
- No alerts without real check failures — empty open list means quiet or no runs, not simulated green.