"The server is up" is four different claims depending on which layer answered. Each check confirms everything below it and nothing above it, which means the layer you choose decides which outages you are capable of noticing.
The stack, and what each rung confirms ¶
DNS resolution
Proves: a resolver returned an address for the name.
Does not prove: that the address is correct, current, or reachable. A stale record resolves beautifully to a machine that no longer belongs to you. Resolution succeeding is the weakest possible good news.
Misses: everything after it. But when DNS is the failure, nothing above it will tell you so clearly — a monitor that only reports "site down" during a DNS problem sends you looking at servers.
ICMP ping
Proves: a host at that address responded to an ICMP echo.
Does not prove: that any service is running. A machine with every application dead still answers ping perfectly, which is why ping-based monitoring is close to useless for web services and still surprisingly common.
Also: plenty of hosts drop ICMP by policy. A ping failure frequently means "firewalled", not "down", so it produces false positives and false negatives at the same time.
TCP connect
Proves: something is listening on that port and completed a handshake.
Does not prove: that the listener is the service you want, or that it can do anything. A web server that has exhausted its worker pool still accepts connections; it just never answers them.
Misses: every application-layer failure. A TCP check is green throughout a total 500-error outage.
TLS handshake
Proves: a valid certificate chain for that hostname, and a working cipher negotiation.
Does not prove: anything about the application. But it catches a failure class nothing else does — certificate expiry, which is both entirely predictable and one of the most common causes of a sudden total outage. Worth checking on its own schedule, with alerting on days-remaining rather than on failure, because by the time the handshake fails you are already down.
HTTP request
Proves: the application answered, with a status code.
Does not prove: that the answer was correct. This is the gap most monitoring falls into, and it is worth being blunt about: a 200 is a claim about the transaction, not about the content. A maintenance page served with a 200 tells every uptime monitor in the world that the site is healthy.
HTTP request with a content assertion
Proves: the application answered, and the answer contained something only a working system produces.
This is the only layer that catches a page which renders an error inside a successful response — and that is the shape of most partial outages. Pick a string that a broken backend cannot produce: a price, a record count, a timestamp. Not the product name in the page chrome, which survives almost any failure.
What differing request SHAPES add ¶
Beyond the layer, the shape of the request matters, and this is the part most monitoring skips. The same URL fetched four ways can produce four answers:
- HTTP/1.1 versus HTTP/2: negotiation failures and protocol-specific bugs are invisible unless you try both.
- Browser User-Agent versus a bot-shaped one: WAFs and bot managers routinely serve one and refuse the other. If your monitor looks like a bot and gets a 403, the site is fine and your check is wrong.
- GET versus HEAD: many origins refuse HEAD with a 405. That is a fact about the method, not the service, and treating it as a failure is a false positive with a schedule.
This is what the four probe methods on this site are for, and the honest framing is that they measure request-shape diversity rather than geography. Why that distinction matters.
Choosing a layer ¶
| If you care about | Check at least |
|---|---|
| Is the box alive | TCP connect |
| Is the web server alive | HTTP status |
| Can a user do the thing | HTTP + content assertion |
| Will it break in 30 days | TLS expiry, on its own schedule |
| Is it broken only for some clients | Several request shapes |
Most teams monitor one rung lower than they think they do, and the gap is invisible until an outage lands in it. If your monitor cannot tell the difference between a working checkout and a 200-with-an-error-message, that is the outage you will find out about from customers.
When the layers disagree, the disagreement is the diagnosis ¶
Running several layers at once is more useful than running the highest one, because the boundary between the last green rung and the first red one names the component that failed.
| DNS | TCP | TLS | HTTP | Where the fault is |
|---|---|---|---|---|
| fail | - | - | - | The record, the registrar, or your resolver |
| ok | fail | - | - | Host down, firewall, or wrong address in the record |
| ok | ok | fail | - | Certificate expired, wrong hostname, or protocol mismatch |
| ok | ok | ok | 5xx | The application, or something it depends on |
| ok | ok | ok | 200, wrong body | A dependency behind the application |
That last row is the one a status-code check cannot produce, and it is the most common real outage of the five.
Two things worth checking on their own schedule ¶
Not everything belongs in the every-minute loop.
- Certificate expiry, daily, alerting on days remaining rather than on failure. A handshake failure means you are already down; thirty days notice means you are not going to be. This is one of the very few outages that is entirely predictable and still happens constantly.
- The DNS record itself, not just resolution. Compare what the authoritative nameserver returns against what you expect. A record silently changed by an expired dynamic-DNS client, or by someone else's migration, resolves perfectly to the wrong place — and every check above it will report a healthy service that is not yours.