Is the website down, or just you? Four checks that settle it

A site will not load. Before you tell anyone, or reboot anything, it is worth spending a minute finding out where it actually breaks. "Down" is not one condition. A browser shows you the same blank failure whether the name failed to resolve, the connection was refused, the certificate was rejected, or the server returned an error, and those four have nothing in common except the outcome.

The good news is that checking them is fast and mechanical. Four questions, in order, and the first one that fails tells you what to do next.

The four layers where "down" happens

Loading a page means completing four separate steps. Each can fail on its own while the others work perfectly.

1. The name has to resolve

   A DNS lookup turns the hostname into an address. Run it twice, once against your normal resolver and once against 1.1.1.1. If yours fails and the public one works, the site is fine and your resolver is not. If both fail, the domain itself has a problem: an expired registration, deleted records or broken nameservers.

2. Something has to accept a connection

   A TCP connect to port 443 says whether anything is listening at that address. Refused means a server answered and said no, which usually means the web server is stopped. Timed out means packets are vanishing, which points at a firewall or a route problem. The distinction matters, and a browser hides it completely.

3. The certificate has to be acceptable

   A TLS inspection shows expiry, the hostnames covered, and the issuer chain. An expired certificate takes a site offline just as effectively as a dead server, and it is one of the most common causes of a site that was working yesterday.

4. The server has to return something useful

   An HTTP(S) Check gives you the real status code and the redirect chain. A 502 or 503 means the site is up and its application is not. A redirect loop means a configuration mistake. A 200 means the server is fine and the problem is in the page itself, or in your browser.

Four checks, well under a minute, and you know which of four very different problems you have.

The single most useful test

If you do only one thing, do this: try it from a completely different network.

On a phone, turn Wi-Fi off and use cellular data. That one switch changes your IP address, your route, your DNS resolver and your ISP simultaneously. If the site loads on cellular and not on Wi-Fi, the problem is on your network or at your provider, and no amount of investigating the website will help. If it fails on both, the site really is having trouble.

This is also the fastest way to detect the awkward middle case: a site that is up for the world but blocked, filtered or misrouted for you specifically. Corporate filters, DNS based ad blockers, parental controls and overzealous security software all produce failures that look exactly like an outage.

# Run these on Wi-Fi, then again on cellular, and compare
https://netdebug.app/open/dns?target=example.com&server=1.1.1.1
https://netdebug.app/open/portconnect?target=example.com&port=443&protocol=tcp
https://netdebug.app/open/http?target=https://example.com

Failure signatures at a glance

DNS	TCP 443	HTTP	Most likely cause
Fails on yours, works on 1.1.1.1	n/a	n/a	Your resolver. Change DNS and retry.
Fails everywhere	n/a	n/a	Domain expired, records deleted, or nameservers down.
Works	Refused	n/a	Web server stopped or crashed. Something answered and said no.
Works	Times out	n/a	Firewall dropping packets, or a routing problem. Nothing answered at all.
Works	Connects	TLS error	Expired or mismatched certificate.
Works	Connects	502 / 503 / 504	Server is up, the application behind it is not.
Works	Connects	200 but blank page	Front end problem, a broken script, or a browser extension.
Works	Connects	Redirect loop	Misconfigured HTTPS or canonical URL rules.
Works	Connects	403 or 429	You are being blocked or rate limited, not experiencing an outage.

That last row deserves emphasis. A site that returns 403 to you and 200 to everyone else is not down. A firewall rule, a geo restriction or a bot detector has decided something about your address, and the fix is entirely different from an outage. More on the 5xx family in the post on 502, 503 and 504 errors.

When it is down for some people and not others

This confuses people more than anything else, and there are four routine explanations.

Anycast and regional edges

Large sites answer from whichever edge location is nearest you. If one region's edge is unhealthy, the site is genuinely down for everyone routed there and completely fine elsewhere. Two people on different continents can honestly disagree about whether a site is working.

A DNS change still rolling out

If the site moved recently, some resolvers hold the old address and some have the new one, so visitors land on different servers depending on which cache they sit behind. This is DNS propagation, and the TTL on the record tells you how long the split lasts.

One ISP has a routing problem

A bad route between your provider and the destination affects only customers of that provider. A traceroute that dies consistently at the same hop, while the site loads fine on cellular, is the signature.

Your own resolver is filtering it

Ad blocking resolvers, corporate DNS and parental controls return a deliberate non answer for blocked domains. It looks exactly like the domain does not exist, which is why the two resolver comparison in step one is worth doing every time.

What "is it down" websites really tell you

Outage aggregators are useful but worth understanding. Most combine two signals: an automated check from their own servers, and user reports.

The automated check tells you whether the site answers from their location, which may be a data centre in a country you have never visited, using a resolver you do not share. A green tick there does not mean the site works for you, and a red cross does not mean it is broken for everyone.

The user reports are more informative in aggregate, but they lag the actual event by several minutes and they spike for anything that inconveniences people, including changes that are not outages at all. A site that redesigned its login flow will produce a report spike indistinguishable from a partial failure.

Use them as a second opinion after your own four checks, not instead of them. Your own test, run from your own network, is the only one that describes your situation.

Reporting it usefully

Whether you are telling a colleague, a vendor or a support desk, a few specifics turn a shrug into an investigation.

• The exact URL, not just the domain. "The site is down" and "this one endpoint returns 502" get very different responses.
• The status code or the precise error. Connection refused, timed out, certificate expired and 503 are four separate incidents.
• Whether it fails on a second network too. This is the detail that most reports lack and that support teams most want.
• The address it resolved to. If you and they are resolving different addresses, that is the entire problem and it will otherwise take an hour to find.
• A timestamp with a timezone. Correlating against server logs needs this, and saved runs in Run History carry it automatically.

If you support a service, keep the four checks saved as a single automation pointed at your own hostnames. Running one tap and exporting the result turns an escalation into a document, and doing it on a schedule means you often notice before anyone reports it.

The short version

Resolve the name against two resolvers, open a TCP connection to 443, inspect the certificate, then fetch the URL and read the status code. The first failure identifies the layer, and a browser shows you none of this. Then repeat the whole thing on cellular data: if it works there, the problem is your network, and if it fails there too, it is genuinely theirs.