Skip to content

How HTTP checks work

An HTTP check does what a browser does, stripped to the essentials: request a URL, see what comes back, judge it. Because the request crosses the entire stack — DNS, network, TLS, web server, application — a passing check certifies a lot at once, which is why HTTP is the default choice for anything with a URL (HTTP monitors).

Anatomy of one check

  1. DNS resolution — the hostname becomes an IP address. An expired domain or broken records fail here.
  2. TCP connection — a connection opens to the server's port. A down host, a closed port, or a firewall fails here.
  3. TLS handshake — for https:// targets, certificates and encryption are negotiated.
  4. Request — the check sends the HTTP request for the URL's path.
  5. Response — the server returns a status code, headers, and a body.

A failure at any step fails the whole check, and that step's error is recorded — which is diagnostic gold: "DNS failure", "connection refused", and "timeout" point at three different culprits. The elapsed time of the full exchange is recorded as the check's response time.

Status codes: the classes

  • 2xx — success; the request was served.
  • 3xx — redirect; the answer lives at another URL.
  • 4xx — client-side errors: not found (404), unauthorized (401), forbidden (403).
  • 5xx — server-side errors: the application, or something behind it, is failing.

UpAll's rule

  • Any status below 400 counts as up. All of 2xx and 3xx pass; 4xx and 5xx fail.
  • Up to 5 redirects are followed, and the final response is what gets judged. Longer chains — usually a redirect loop — fail the check.
  • The timeout is fixed at 10 seconds and isn't configurable. No response within 10 seconds means a failed check.
  • The response body is never inspected. There are no keyword or content assertions: a page that returns 200 while displaying "database connection failed" counts as up.

Two practical consequences follow. First, since 401 and 403 count as down, point monitors at URLs that answer without a login. Second, since content isn't read, the choice of URL carries the intelligence: monitor a page that genuinely exercises the application — one that touches the database and returns a 5xx when unhealthy — rather than a static page that succeeds no matter what.

What an HTTP check can and cannot tell you

A passing check proves that DNS resolves, the network path works, TLS negotiates, the web server is running, and the application produced a non-error response — plus the full-stack latency of doing all that. For https:// targets, UpAll additionally reads the TLS certificate about hourly and opens incidents when it's expired or close to expiring (SSL certificate monitoring).

What it can't prove: that the page's content is correct, that a login-to-checkout journey works, or that background jobs are running. For hosts that don't speak HTTP at all, use Ping or a TCP port check instead. And before saving any HTTP monitor, the Test connection button runs this whole sequence immediately and shows you the result or the exact error (test connection).