Checks, locations & failure confirmation
How this is scored
What can be monitored and how reliably a failure is detected: HTTP(S) with status code and keyword checks, TCP and port, ping, DNS records, SSL certificate and domain expiry, cron jobs and heartbeats, multi-step API checks with assertions, browser or transaction checks of a login or checkout, the shortest check interval, the number and regions of probe locations, the re-check from a second location before an alert, timeouts and response time thresholds, and private locations inside the customer's own network.
0 — Runs no checks of its own; a status page or alerting tool that only receives signals from other monitors.
3 — HTTP checks of a URL at a fixed interval with an up or down result; keyword, SSL, cron and the probe locations are basic or not described.
5 — HTTP(S), keyword, TCP or port, ping and SSL expiry checks, cron or heartbeat monitoring, an interval of one minute or less, several named probe locations, a failure confirmed from a second location before alerting, and response times recorded per check.
8 — Multi-step API checks with assertions on headers and body, browser or transaction checks of a user flow, DNS and domain expiry checks, sub-minute intervals, probe locations listed by city with the confirmation logic documented, private locations or agents for internal services, and maintenance windows that pause checks.
10 — Coverage and accuracy a reliability team runs on: every check type above with code-based checks (for example Playwright or scripted tests) in version control, location-specific thresholds, false-positive handling and probe health published, and the detection method documented so a result can be reproduced.
The SaaS Platform Engineer
The documented set covers HTTP(S) with keyword and forbidden-string matching, JSON body assertions (up to ten, on values and response headers), custom verbs and payloads, TCP with send-string, ICMP ping, full SSL chain validation, DNS records, domain expiry and cron heartbeats with grace periods — checked every minute by default from named cities on six continents, and a failure at the primary location is re-confirmed from a second location in a different city on a different provider before anyone is alerted, which is exactly the confirmation logic I want written down. It sits below the top band because the documented assertions evaluate a single endpoint: we found no public information on multi-step request chains or scripted browser transactions of a login or checkout (Lighthouse audits on desktop and mobile from three continents are the closest documented browser-based check), the shortest documented interval is one minute, and checks are strictly outside-in with nothing installed on the monitored machine — we found no public information on private probe locations inside our own network. 2 3 4 7 14 15 21