Is that website down?
Twenty tools tell you up or down. This one tells you up, and then what the up is hiding.
5 checks a minute and 20 an hour from one address, and 3 a minute for any given domain. Enough for a person, not enough to hammer a site through us.
What a checker answers, and what this one also answers
| The question you actually have | A usual is-it-down tool | This page |
|---|---|---|
| Did the server answer? | Yes, and well | Yes |
| Is the page readable, or did its stylesheet fail? | Not answered | Advantage: UptimeEZ. Nine layout signals, plus the page silhouette |
| Is a database error printed inside a valid page? | Not answered | Advantage: UptimeEZ. Matched against the engine signature list |
| Did the page quietly become noindex? | Not answered | Advantage: UptimeEZ. Checked on every pass |
| When does the certificate expire? | Sometimes | Advantage: UptimeEZ. Expiry date, chain and covered names |
| Is it down from Sydney as well as from Paris? | Advantage: the usual tools. Several probe locations | One location, ours |
| Was it down last night? | Advantage: the usual tools. History on the paid tiers | Not from this page. That needs monitoring |
Two rows go the other way, and they are the honest ones: a single probe location and no history are real limits of a one-off check.
Every reading above is counted in the engine source, which is public: src/Check/Css.php for the layout signals, src/Check/Database.php for the error signatures, src/Diagnose.php for what it tells you to do about them.
The same table with seven other tools in it , or what separates monitoring tools and how to test one.
The two rows above have a page each, because they are what a single reading cannot give you. Watching the page for change over time, and, if the site belongs to somebody else, a read-only link with their sites on it and nothing else.
The certificate row has a tool of its own now, because a date deserves more than one line: read a certificate on its own for the chain, the covered names and the domain expiry, or watch every certificate you are responsible for.
What each answer means, and what to do next
The check returns five readings, not one. Here is what each one is telling you, and the first thing worth doing about it.
The layout reading: the page answered, but did it arrive whole?
A stylesheet that fails to load leaves the server perfectly healthy and the page unreadable. The check fetches every stylesheet the page declares and reads what came back, because a 200 that returns an HTML error page instead of CSS is still a 200. If this reading is not clean, open the page in a private window before anything else: a cache on your side hides the problem from you and shows it to everyone else. Then look at whether the failing file lives under a cache directory, which points at a purge that did not finish rather than at a broken deployment.
The error reading: a database failure wearing a valid page
This is the failure that costs the most, because nothing about it looks like a failure. WordPress serves its database error with a 200, and every checker that only reads the status code reports the site as up. The page body is matched against 41 known failure signatures, 35 of them database messages and 6 fatal PHP traces. If one matches, the fix is almost never in the page: check the database service first, then the disk, because a full disk produces the same message as a dead server.
The indexing reading: the switch someone forgot to flip back
A staging site goes live with its noindex tag still on, and nothing breaks. The site works, the client is happy, and the traffic never arrives. It is found weeks later, usually by accident. This reading looks at the robots meta tag and the X-Robots-Tag header, because either one is enough to hide a page. If it is set and you did not mean it, the tag is usually a checkbox in the CMS rather than a line of code.
The certificate reading: a date nobody put in a calendar
Certificates mostly renew themselves, which is exactly why the failure is silent: the renewal that stopped working stops telling anyone, and the outage arrives ninety days later on a site nobody was thinking about. The reading gives the expiry date, the chain the server actually sends, and the names the certificate covers. A missing intermediate certificate is the one that catches people out, because it works on your laptop and fails on a phone.
The domain reading: the failure no server restart will fix
A domain that expires takes everything with it, and it is the one outage your hosting can do nothing about. It also has the longest recovery time on this page, because renewal and propagation are not instant. The expiry date is read from the registry when the registry publishes it. If it is close, renew before you finish reading this sentence: there is no version of this problem that gets cheaper by waiting.
If it is your own site: the order to look in
Each step rules out a whole class of cause, which is what makes the next one worth doing.
- You or everyone. This check runs from our server, so a failure here is on the site and a success here is between you and it: cached DNS, a captive network, a firewall.
- Does the name resolve. An expired domain or a changed record takes everything down, and no restart touches it. Longest recovery on this page, so rule it out first.
- Does anything answer. Nothing answering points at the server; an error code answering points at the application. Two different people to call.
- Does it answer wrongly. A database error inside a 200 is called healthy by anything that stops at the code. Check the service, then the disk: a full disk says the same thing as a dead server.
One thing not to do first: restart. It clears the evidence, it fixes the symptom often enough to be believed, and the outage comes back that evening with nothing left to look at.
These five readings are one snapshot, taken now. Four of them only mean something when you have yesterday to compare against, which is the difference between checking a site and monitoring one. The full list a check should read, and how far each reading is allowed to go, is on what a health check reads.
Questions people actually ask
Why does a site show as up when visitors say it is broken?
Because "up" only means the server answered. A WordPress site whose stylesheet failed to load answers 200 with a page that visitors cannot read. A site whose database is unreachable often answers 200 with the error printed inside an otherwise valid page. Counting the answer and reading the answer are two different jobs.
What does a 200 status code actually prove?
That something at that address returned a document. It says nothing about whether the document is the right one, whether it is readable, whether it still allows search engines to index it, or whether the certificate expires next week. Those are separate readings, and a checker that stops at the status code cannot make them.
Is the site down for everyone, or just for me?
This check runs from our server, not from your machine, so if it answers here and not for you, the problem is between you and the site: DNS cached on your side, a captive network, or a firewall rule. If it fails here too, the problem is on the site.
Can this tool be used to hammer a site?
No, and that took deliberate work. Five checks a minute and twenty an hour from one address, and no more than three checks a minute for any given domain whoever asks. That last limit is the one that matters: without it, a few hundred visitors each staying within their own quota would add up to a flood on one target, sent from our address.
Does one check tell me whether the site was down last night?
It cannot. A single reading describes one second. Answering "was it down at 3am" needs something that was already watching at 3am, which is the difference between a checker and monitoring.
You had to come here and type an address
Which means you already suspected something. Monitoring is the version where you hear about it first, and where the message says what to check rather than just that something broke.