Uptime
The Uptime Check asks whether your target answers. Every Monitor has one, and it is always on. Its status decides whether the Monitor is up or down, and its Incidents are the only ones that count against your uptime percentage.
How often it runs
Section titled “How often it runs”Each of the Monitor’s locations runs it once every Interval, on its own schedule. So a Monitor on three locations sends three requests every Interval, one from each.
A Heartbeat Monitor is not run from our locations. Your job calls us, and a call that does not come in time is the failure: see Heartbeat Monitors.
What fails a run
Section titled “What fails a run”A run fails when the target does not give the answer the Monitor expects.
- Website and API: the name cannot be found, its address is a private one, the connection is refused or closed, the secure (
https) connection fails, the certificate has expired or is not trusted, no answer comes within the Monitor’s timeout, a redirect cannot be followed, the status is not one the Monitor expects, or a keyword or JSON assertion is not met. - TCP: the port does not take the connection within the timeout.
- Ping: no reply comes, or more pings go unanswered than the Monitor’s Maximum packet loss allows.
- Heartbeat: your job does not call within its expected interval and its grace.
Each run on the Monitor’s Runs tab says what went wrong, in words.
From a failed run to an Incident
Section titled “From a failed run to an Incident”One failed run is not an Incident yet. A run that fails is tried again from the same location 5 seconds to 10 seconds later. If that try works, the run counts as up, and nobody is alerted.
If it fails again, the Monitor’s other locations are asked to look, and an Incident opens when most of the locations that answered agree. A Monitor with one location opens the Incident after its own second try. How a failure is confirmed tells the whole story.
IPv4 and IPv6
Section titled “IPv4 and IPv6”Many targets can be reached at two kinds of address, IPv4 and IPv6. The run that decides whether your target is up uses IPv4 when the target has an IPv4 address. After a run that passes, the location also tries the other kind of address, at most every 10 minutes from each location.
When the target answers over one and not the other, and the other locations agree, the Uptime Check raises a warning:
acme.com does not answer over IPv6 from Frankfurt and Helsinki. It answers over IPv4.
It is a warning, and not down: most of your visitors still reach the target, because browsers try both kinds of address. Some visitors, and API clients that use only one kind, cannot. So it never counts against your uptime, never shows on your Status page, and waits for a digest like every warning. A location whose own IPv6 does not work is never asked about IPv6.