One bad check stays one bad check.
A failed check is tried again, then from another region. Your status page changes, and someone is paged, only when the failure is real.
A network blip
- 14:02:10Dublin: 503
- 14:02:12Dublin, again: 200
- Nothing changes. Nobody is paged.
A real outage
- 14:02:10Dublin: 503
- 14:02:12Dublin, again: 503
- 14:02:40Virginia: 503
- 14:03:00Incident opens. Status page updates.
Your status page reads from it.
A component’s status comes from its monitor’s confirmed state, so the page changes when the monitor does and never on a single failed check.
Daily uptime adds up into the 90-day history on the page. Planned maintenance doesn’t count against it.
Several regions, one answer.
On every plan, a failure is re-checked from other regions before it counts. On Pro and above, a monitor can run from several regions at once and only goes down when most of them agree.
Websites and APIs, keyword and JSON checks, TCP ports, DNS records, game servers, and heartbeats for cron jobs.
What a monitor does
- Websites and APIs
- Status codes, response times, and whether a keyword or JSON value is in the response.
- Heartbeats
- Cron jobs and workers ping a URL on each run. A missed ping opens an incident.
- Ports, DNS and game servers
- TCP connections, DNS records, and game-server queries.
- Slow counts as degraded
- Set a response-time limit per monitor. Slower answers mark the component degraded.
- Warming up
- A new monitor reads as warming up until it has passed a few checks in a row, so a page never shows all clear too early.
- One incident, one alert
- An incident opens after a run of failures and resolves after a run of passes. A brief recovery stays part of the same incident.
- Bulk setup
- Paste a list of URLs to create monitors in one go, then pause, resume or edit them together.
- Check intervals
- Every 5 minutes on Free, every 2 minutes on Solo, and every minute on Pro and Business.
