Diagnostics · updated 20 August 2026
How to tell if a website is really down (and not just down for you)
A five-minute diagnostic that separates a genuine outage from a problem on your own machine, network or ISP.
Most "the site is down" moments are not outages. They are a stale DNS record, a cached error page, an ISP resolver having a bad afternoon, or a VPN exit node the site has blocked. Working out which one you are looking at takes about five minutes and saves you from raising a support ticket that says nothing useful.
Step 1: check from outside your network
The single most useful test is one that shares nothing with your setup — a different machine, a different network, a different DNS resolver. That is exactly what an external checker does. Run the website status checker: if it gets a normal response, the site is up and the fault is between you and it. If it fails too, the outage is real and you can stop debugging your laptop.
Step 2: read the failure, not the verdict
"Down" is not a diagnosis. There are four distinct ways a request fails, and they have nothing in common:
- DNS failure — the name cannot be turned into an address. The domain may have expired, or a nameserver change has gone wrong. The server itself may be perfectly healthy.
- Connection refused — the machine answered, but nothing is listening on port 443. The web server process has stopped or crashed. This is usually the quickest to fix and the easiest to spot.
- Timeout — packets go out and nothing comes back. A firewall is dropping traffic, a route is broken, or the server is so loaded it cannot accept new connections.
- TLS error — the connection opens but the certificate is expired, mismatched or incomplete. The site is running; browsers simply refuse to show it. This is the classic Monday-morning outage.
Step 3: rule out your own machine
If the external check says the site is up, work down this list in order — it is roughly cheapest-first:
- Hard-refresh the page (Ctrl+F5, or Cmd+Shift+R). Browsers cache error pages more eagerly than people expect.
- Try a private window with extensions disabled. Ad-blockers and privacy extensions can block a whole domain.
- Switch to mobile data. If it loads, the problem is your broadband, your router, or your ISP.
- Change your DNS resolver to 1.1.1.1 or 8.8.8.8. ISP resolvers occasionally hold a broken or poisoned record for hours.
- Turn off any VPN. Plenty of services block commercial VPN ranges outright.
- Check the clock on your device. A wrong system time makes every TLS certificate look invalid.
Step 4: if it is your site, find the failing layer
When the outage is genuine and it is your own site, resist the urge to restart everything. Establish which layer is broken first:
- DNS lookup — does the domain still resolve, and to the address you expect? A surprising number of "server down" incidents are actually a DNS change nobody remembers making.
- Ping — is the machine reachable at all? If ping works but HTTP does not, the server is alive and the web service is not.
- Port check — is anything listening on 80 and 443 from outside? This distinguishes a stopped service from a firewall rule.
- SSL check — has the certificate expired? Look at the days-remaining figure; automated renewal failing silently is one of the most common causes of a sudden total outage.
Step 5: know before your customers do
Almost every small business finds out about downtime from a customer. That is the wrong order. A free monitor checks the site every five minutes and emails you when the state changes, so the first message you get is from a machine rather than a frustrated buyer. It costs nothing and takes a minute to set up — and the alert email carries the status code and error, which means you start the diagnosis already halfway through this list.
The uncomfortable case: up but broken
One caveat worth holding on to. A site can return HTTP 200 on its home page while its login, checkout or API is failing. External checks measure availability, not correctness. If your monitoring is green and customers are still complaining, point a monitor at a URL that exercises the thing that matters — a health-check endpoint that touches the database, for instance — rather than the marketing home page that is served from cache.