When Checkly pages you, it's real

Two layers. First, retries: every failed run can be retried with fixed, linear, or exponential backoff (from the same region or a different one), so transient network blips resolve themselves. Second, escalation policies: you decide whether an alert fires on the first confirmed failure, the third, or only after minutes of sustained failure. Nothing pages your team until both layers agree it is real.

18+ channels: Slack, PagerDuty, Opsgenie, Microsoft Teams, email, SMS, phone calls, Discord, Telegram, incident.io, Rootly, FireHydrant, ilert, Spike.sh, Splunk On-Call, GitLab Alerts, StatusPage, and fully customizable webhooks for everything else.

Yes. Alert channels, retry strategies, and escalation policies are all TypeScript constructs in the Checkly CLI: versioned in git, reviewed in pull requests, and deployed alongside your checks from CI. Prefer clicks? Everything has full parity in the web app, and there is a Terraform provider too.

Run-based escalation alerts after N consecutive failed runs; time-based escalation alerts after a check has been failing for N minutes. Both support reminders, re-sent at 5, 10, 15, or 30 minute intervals up to a cap you set, and both stop automatically the moment the check recovers. For checks running in parallel across locations, you can also require a percentage of locations to fail before alerting.

Each channel independently subscribes to failures, degradations, recoveries, and SSL certificate expirations (with a configurable day threshold). Combined with per-check and per-group subscriptions, that means the payments team can get paged for failures while a #performance channel only hears about degradations.

Use a webhook channel. You control the URL, method, headers, and body. Handlebars-style variables like {{CHECK_NAME}}, {{ALERT_TYPE}}, and {{RESULT_LINK}} inject the alert context, and {{VARIABLE}} references resolve secrets from your environment at send time. Nothing gets hardcoded.