the check lifecycle
How does uptime monitoring work? Probe, confirm, alert, recover
Uptime monitoring works by sending a small probe to your site at a fixed interval, treating a timeout, error code or bad content as a failure, confirming that failure from a second region, then alerting the on-call person within seconds.
▸ lifecycle, compressed
probe every 30 s
↓ fail ▸ confirm 2/2 regions
↓ down ▸ alert <10 s · sms + slack
↓ 3 green probes ▸ recovered · logged
-
01
The probe sends a request every 30 seconds
A probe is a real request, sent the way your users send one: an HTTP GET with your headers, a ping, or a TCP handshake on the port you chose. For HTTP checks it follows redirects, validates the certificate, and inspects the body for the keyword or JSON assertion you defined. Four things count as a failure, nothing else does:
▸ GET https://yourdomain.com/health from EUC
200 OK · 187 ms · cert valid 62 d · keyword "ok" found
fails only if:
timeout > 30 s · HTTP 5xx · keyword miss · cert invalid
-
02
Second-region confirmation so you never get paged for a blip
One failed probe proves very little. Routes flap, ISPs hiccup, a single peering point can drop packets for 20 seconds while your site is fine for everyone else. So a failure in one region immediately triggers a re-probe from the other one. Only a 2-of-2 quorum, US East and EU Central both failing within seconds of each other, is treated as a real outage. That quorum is the difference between an alert you trust at 3am and one you sleep through.
EUC eu central timeout 30.0 s
USE us east · re‑probe timeout
DOWN · confirmed 2/2 · 6 s after first failure
-
03
The alert reaches the right person in under 10 seconds
On confirmation, AlertPing resolves your escalation chain: who is on call right now, which channels they get, and who is next if nobody acknowledges. The page goes out by SMS, email, Slack and webhook in under 10 seconds, and your status page flips to investigating on its own. Every channel is included in every plan; see downtime alerts for the full routing options.
▸ resolve chain "payments on-call" · 03:42:04
1 → maya (on call 22:00-08:00) · sms + slack sent
2 → deniz · fires if no ack in 5 min
3 → #incidents · whole channel
status page → investigating · webhook → delivered
-
04
Recovery and the incident log
Recovery gets the same skepticism as failure: three consecutive green probes before anything is declared. Then the resolution alert goes out, the status page flips back, and the incident is written to the log with first failure, confirmation, alert and recovery timestamps. That log feeds your uptime history and the SLA reports on Business and up, so the 3am incident is already documented when you open the postmortem.
03:43:02 EUC 200 OK 214 ms
03:43:12 USE 200 OK 198 ms
03:43:26 EUC 200 OK 231 ms · 3rd in a row
RECOVERED · downtime 94 s · incident #4812 logged
your side of it
Setting up uptime monitoring takes four steps
No agent, no code change, no deploy. Want to see the lifecycle run before you set anything up? Check your website status live, or read the uptime monitoring FAQ for what counts as downtime.
-
1
Add a monitor
Paste a URL, IP or port. Pick HTTP, ping, port, SSL or cron heartbeat, and add a keyword or JSON assertion if you want content checked too.
-
2
Choose interval and regions
30-second checks by default (60s on Starter, 15s on Enterprise), probed from US East and EU Central with second-region confirmation.
-
3
Connect alert channels
Add phone numbers, Slack, email and webhooks, then set the escalation chain and on-call hours so the right person wakes up.
-
4
Publish your status page
One click hosts a branded status page fed by your checks. Customers subscribe for updates, and it flips state automatically during incidents.
You've seen the lifecycle. Put your site on it.
Probe, confirm, alert, recover: running against your first monitor in under a minute.