Alerts

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.

• 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.

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 Integrations.

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.

• Monitoring overview
• Health & Checks
• Incidents
• Status Pages