Blog
How Things Work Web Basics

How to Actually Tell If a Website Is Down (Not Just Broken for You)

July 22, 2026 3 min read

What you'll learn

  • Why your own browser can't tell the difference
  • What an HTTP status code is actually telling you
  • Why a site can be down for you but fine for everyone else

A site won't load, and the first question is always the same: is it down, or is it just you? Your browser genuinely has no way to answer that. A failed page load looks identical whether the problem is your Wi-Fi, your ISP, a DNS server somewhere between you and the site, or the site's own servers being offline — the browser just shows a generic error either way.

Your browser only knows its own story

When a page fails to load, your browser reports what happened on your end — it timed out, it couldn't connect, it got no response. What it can't tell you is why. If your home router is having a bad day, if your ISP's DNS servers are slow to resolve the domain, or if the site's server has actually crashed, all three produce the same blank page and the same unhelpful error message. The only way to rule out your own connection is to ask a completely different machine — one on a different network — to try the same request. That's the entire premise behind a server-side uptime check: it's not doing anything clever, it's just asking from somewhere that definitely isn't your house.

What a status code is actually telling you

When a check succeeds, the number that comes back matters more than a simple yes or no. A 200 means the server responded normally — the page is genuinely fine. A 404 means the server is up and responding, but that specific page doesn't exist, which is a completely different problem from an outage. A 500 or 503 means the server is alive but something broke while handling the request, often a backend error or the app being overloaded. And no response at all — a timeout — usually points to something lower-level: the server isn't listening, DNS couldn't resolve the domain, or a firewall is blocking the connection entirely. Each of these needs a different fix, which is exactly why a plain "it's down" isn't very useful on its own.

An expired SSL certificate produces its own distinct failure. The connection never even gets far enough to receive an HTTP status code — the browser refuses the connection during the security handshake and shows a certificate warning instead. It looks like the site is down, but the server itself might be running perfectly fine.

Why "down for me" isn't the same as "down for everyone"

Even a check from a completely different server can give a result that doesn't match what everyone else is seeing. Large sites often serve traffic from multiple regional data centers, so an outage in one region can leave the site fine everywhere else. DNS changes take time to propagate, so a domain can point to a new server for some visitors and an old, dead one for others, for hours. And increasingly, some sites deliberately block requests that look automated — coming from a data center rather than a home internet connection — which can make a perfectly healthy site report as blocked or erroring on an automated check, even though real visitors load it without any trouble.

None of that means uptime checks aren't useful — they're still the fastest way to rule your own connection out of the equation. It just means a single check, from a single location, is one data point, not a verdict.

Tools mentioned in this post

0 comments

Leave a comment

Comments are reviewed before they appear publicly.