How downtime is confirmed

A single failed request does not wake you up at night. By the end of this page you will know which steps turn a failed check into an incident. You will also know what the monitor cannot see.

This page covers HTTP monitors. Heartbeat and expiry monitors work differently, as the last section explains.

What counts as a failed check#

Each check is a plain GET request that follows up to five redirects. The check fails for any of these causes, shown as the incident's cause:

• "HTTP" plus the status code, such as "HTTP 503". The page answered with something other than status 200.
• "keyword check failed". The page loaded, but your keyword was missing.
• "timeout". The page did not answer within 10 seconds.
• "DNS lookup failed". The host name did not resolve.
• "TLS handshake failed". The secure connection could not start.
• "connection refused". The server turned the connection away.

A second location confirms every failure#

When a check fails, a second location runs the same check right away. The failure only counts when both locations see it.

If the second location sees the site up, the check counts as inconclusive. Nothing changes, and no incident opens.

Two guards against false alarms#

• Our own connection drops. Before judging any failure, the checker confirms it can reach the internet. If our own checker loses connectivity, we discard that round instead of alerting you.
• The second location has trouble. If the second location fails for many sites at once, its confirmations are not trusted. New incidents wait until it recovers.

These guards filter out many false alarms, but not every one. A firewall that blocks checkers at both locations still looks like downtime.

When an incident opens#

1. The first confirmed failure marks the monitor down and opens an incident. The incident's start time is that check.
2. The down alert goes out once the confirmed failures in a row reach your Alert after setting. With 1, that is the first failure.
3. The incident keeps the start time of the first failure, whatever Alert after says.

The time to an alert is about the check interval times Alert after, plus a few seconds to confirm. On Free, checks run every 5 minutes. So detection alone can take up to 5 minutes there.

When an incident closes#

A down monitor needs two successful checks in a row to count as up again. The incident ends at the first of those two checks. The recovery mail goes out after the second.

A new or resumed monitor is different. It goes up on its first successful check and closes any incident still open.

What no monitor can catch#

Checks are samples. An outage shorter than the gap between two checks can slip through unseen. A faster check interval shrinks that gap.

Each check requests the page itself and nothing more. Scripts, images and other files on the page are not loaded.

Heartbeat and expiry monitors#

These monitors open and close incidents from a single reading. A missed heartbeat deadline opens an incident at once, and the next ping closes it. An expired certificate or domain opens one at the daily check. A valid date at a later check closes it.

Neither type uses the second location or Alert after.