These are the causes ErrorDetector names on an incident, in the same words the incident page uses: what happened, what it usually means, and what to check first. Generated from the product's own tables, so a new cause gets a page automatically.
Nothing answered. These open an incident and count against uptime.
The name of the site could not be turned into an address, so no connection was ever attempted.
The server exists and answered, but nothing was listening on the port the monitor connects to.
The connection opened, but the certificate exchange did not complete, so no request was sent.
The server accepted the connection and then dropped it mid-request.
There was no network path to the server at all.
A connection was attempted, but nothing came back before the monitor gave up waiting.
The URL redirected again and again until the limit was reached, so no page was ever delivered.
The site answered but the check failed. These alert without touching the uptime figure.
The page loaded normally, but the text the monitor looks for was not in the response.
The target answered correctly, but later than the response-time limit set on the monitor.
The API answered with a success status, but the body did not contain the text or the JSON value the monitor expects.
The request was stopped before it reached the application: a bot filter, a WAF rule or an IP allowlist.
The endpoint requires authentication and did not accept the request.
The server understood the request and refused it.
The server answered normally, but the exact path being monitored no longer exists.
The target rate-limited the checks.
The application itself raised an error. The server is up; something inside it failed.
A proxy in front of the application could not get a valid response from it.
The service reported itself unavailable.
A proxy in front of the application gave up waiting for it.