Checks & incidents

What a check does, and when it becomes an incident.

What one check does

We send your method (GET by default) with your headers and body, wait up to your timeout, and record the status code, the response time and the size. Redirects are followed when you ask, up to five hops, and every hop is re-validated.

What counts as a failure

Result	Verdict
Expected status code	Pass
Different status code	Fail — unexpected status
No response within the timeout	Fail — timed out
DNS failure, refused connection, TLS error	Fail — could not connect
Body missing the required string	Fail — did not match
Slower than your limit	Fail — too slow

When a failure becomes an incident

Not on the first one. Each monitor has a failure threshold, default two. Two consecutive failures open an incident and send one alert; the next successful check closes it and sends one more.

That is the whole alerting policy. A provider that stays down for six hours produces two messages, not three hundred — because a tool that cries wolf gets muted, and a muted tool is worse than none.

Where we check from. One region, in Europe. We will tell you your service is unreachable from our network, not from every network. Multi-region checks are on the list and are not here yet.

Private addresses

Monitors cannot target private, loopback or link-local addresses. Anything else would make us a request-forgery proxy pointed at whatever shares our network — including cloud metadata endpoints.