Reading the result
When a site won’t load, the first useful question isn’t “why” — it’s “is it me?”. Your browser can’t answer that, because everything it knows comes through the connection that might itself be the problem. A request from somewhere else settles it in one step.
- 2xx or 3xx — up. The server answered normally. If you still can’t open it, the fault is between you and the site: your network, a VPN, a stale DNS entry on your resolver, or your ISP.
- 4xx — reachable, but refusing. The server is alive and talking. A 404 means that page isn’t there; a 403 means it’s there and you’re not allowed in — sometimes because a firewall or bot filter blocked our request specifically.
- 5xx — the server is failing. It answered, but with an error of its own: 500 for a crash in the application, 502 and 504 when something behind a proxy stopped responding, 503 when it’s overloaded or in maintenance. This one is genuinely on the site’s side.
- No response — nothing answered. No connection before the timeout. The server may be off, a firewall may be dropping traffic silently, or the domain may point somewhere that no longer exists.
What this check deliberately ignores
A broken or expired TLS certificate does not count as down here. The site is running; browsers are simply refusing to display it. That’s a separate failure with a separate fix, and the free SSL checker is the right tool for it. Likewise a domain that fails to resolve is reported as a DNS problem rather than an outage — you can see the records themselves with the DNS lookup.
One vantage point, and what that means
We check once, from one server in Europe. That’s enough to answer the question you came with — whether the site responds to the outside world at all. It is not enough to prove the site is reachable everywhere: regional routing problems, geo-blocking and CDN failures in one region are all invisible from a single vantage point. If that’s what you need to know, use a service built for uptime monitoring, which checks continuously from several regions.
The outages nobody checks for
Here’s the honest part, and it’s the reason this tool sits on a domain monitoring site. Domain Monitor Hub does not do uptime monitoring. It won’t ping your site every minute and it won’t tell you the server fell over.
What it does watch is the layer underneath — and that layer causes outages an uptime check can never warn you about, because it looks perfectly healthy right up to the moment it doesn’t. A registration that lapses takes the site, the email and the certificate down together, on a date that was known months in advance. An expired certificate turns every visit into a full-page security warning while the server keeps answering 200. A changed DNS record quietly sends your traffic somewhere else. A transfer lock coming off in WHOIS is often the first visible step of a hijack.
Uptime monitoring reacts after the site is already down. This watches the things that put it there — and warns you while there’s still time to act. Use both: they answer different questions.