Website status: seven layers, and free checkers read four
Loading a website is seven questions in a row, and each one can fail on its own. A status check is a decision about how many of them to ask.
| Layer | The question | What fails there |
|---|---|---|
| 1. Resolution | Does the name give an address, and the right one | Expired domain, deleted record, stale AAAA, registrar lock |
| 2. Connection | Does something accept TCP on 443 | Host down, service stopped, firewall |
| 3. TLS | Does the handshake complete, with a valid certificate | Expiry, missing intermediate, protocol mismatch |
| 4. Status | What number comes back | 502, 503, 504, 500 |
| 5. Body | Is there content, and is it the right content | Soft 404, empty listing, error printed at 200, missing stylesheet |
| 6. Render | Does it assemble into a page | Failed script, blocked asset, layout collapse |
| 7. Function | Does the thing the client sells still work | Form delivering nowhere, checkout failing at step three |
A free checker answers one to four. That is not a criticism, it is a description of the product: you type an address, you want an answer in two seconds, and layers five to seven require knowing something about the site that a stranger cannot know.
The problem is that layers five and six are where a maintained client site spends most of its broken time, because layers one to four are the ones that have alarms on them already.
What free checkers are genuinely better at
Two things, and pretending otherwise would be dishonest.
Geography. A public checker queries from a dozen countries at once. A single probe, self-hosted or otherwise, sees one path. When a client's visitors in one region cannot reach a site that is up everywhere else, the multi-location view is the tool that finds it, and it finds it in seconds.
The one-off question. Somebody says a site is down. You want to know now, about a domain you may not manage, with no setup. Nothing beats typing it into a box.
Where they stop being the right tool is when the question changes from "is it down" to "tell me before the client does". That is a different job, it runs unattended for years, and it needs to know what this particular site looks like when it is healthy.
The three assertions that close the gap
None of these requires a particular product. Any checker that lets you express them will do, and a cron job with curl will do it too.
A string that must be present. Pick, per site, one piece of text or markup that only appears when the page has done its job. Not the site name, which lives in the template and survives every failure worth catching. The price block. The first product card. The submit button of the form that generates leads.
curl -sS https://example.com/pricing | grep -qF 'data-price' || echo BROKENA response size that has not collapsed. An empty listing and a page that lost its stylesheet both change the byte count sharply while keeping the status at 200. Comparing against the last known good size costs nothing and catches a category of failure that no status code will ever describe.
Certificate lifetime, read from the connection. Not the renewal job's exit code, which is on a machine you may not have. The date the server is currently serving, from outside, with an alert threshold set below the renewal margin rather than at the deadline. The arithmetic behind that threshold is in renewal is three operations.
The expected status is not always 200
This is the setting most tools do not expose, and its absence causes more ignored alerts than any other single thing.
A staging site behind HTTP authentication answers 401 permanently. It is working. Configure the check to expect 401 and an unexpected 200 becomes the alert, which is exactly right, because a staging copy that stopped asking for a password is a real incident and one that ends with the copy in Google's index.
A maintenance window should answer 503. The alert worth having is the 503 still there an hour after the window closed, not the 503 during it.
A URL that was deliberately retired should answer 410, and the alert is if it starts answering 200 again because somebody restored a backup.
Three normal states, three tools that will page you at three in the morning about nothing, three teams that learn to dismiss the notification without reading it. The full argument about which codes deserve an alert, which deserve a counter, and which mean nothing until you read the body, is in what a 200 does not prove.
Layer seven, and being honest about it
Nothing described above tests whether the contact form delivers, whether the checkout completes, or whether the booking calendar has availability. Those need a scripted browser walking through the steps, which is a different category of tool with a different price and a different maintenance burden: every design change breaks the script, and a script that is broken half the time is worse than no script.
The pragmatic middle is a canary. Have the form send to a mailbox you own, on a schedule, and treat the absence of that message as the alert. It tests the whole chain including the parts you cannot see, it costs almost nothing, and it fails loudly in exactly the case that matters. Mail is also the failure mode your web checks are structurally blind to, which is the MX problem.
The canary is worth naming properly, because it inverts the whole model. Every check described so far sends a request and reads what comes back; this one waits for a signal and treats its absence as the failure. That is the only shape of check that can see a backup, a report or an import that never ran at all, and it is how you detect an absence.
What to do with all of this
If you look after ten or more sites, the useful exercise is not choosing a tool. It is writing down, once per site, what "working" means: which URL, which status, which string, which hostname's certificate. Add one more line while you are in there, because it is the cheapest of the lot and it is wrong on most sites: the date each page claims it last changed, which is the one field in a sitemap Google actually reads. That document is worth more than the monitoring, because it survives changing tools and it is the thing a new colleague needs on their first day.
Then pick something that can express it. Our own is built around exactly these layers and it is open source, so you can read what it checks rather than take our word for it, and you can run one address through it here to see the shape of the output. It is not the only reasonable answer, and where the alternatives are stronger is set out plainly in the comparison.
