Is a website down for everyone or just me? A step-by-step diagnosis

Step 1: Read the error, do not just reload

The wording of the error already narrows the cause. Chrome-style messages are the most common, and the layer they point to is fairly consistent.

An HTTP error such as 502 or 503 is actually good news for diagnosis: the name resolved, the connection worked and the certificate was accepted. The fault is on the server side.

Step 2: Walk the path

1. Does the name resolve? If a lookup says NXDOMAIN, the name is misspelt, expired at the registrar, or its records were removed. A status of SERVFAIL points to a broken zone or failing nameservers. The DNS records guide explains how to tell the two apart.
2. Does HTTPS answer from your browser? A reachability probe only says whether a connection came back and how long it took. It cannot tell a refused connection from a bad certificate, because the browser hides the reason from page scripts.
3. Is the certificate valid for this name? Check the expiry and the coverage, as described in the certificate expiry guide. A date problem on only one device usually means that device's clock is wrong.
4. Does a different network work? Switch your phone to mobile data and open the same address. If it loads there, the site is up and the problem is between you and it: your Wi-Fi, your provider, a DNS filter, or a router cache.
5. Does a clean browser work? Try a private window, and then another browser. Extensions that block content, rewrite requests or force HTTPS are a frequent hidden cause, as are stale cookies and cached redirects.
6. Does the other name work? Try www.example.com and example.com separately. They often point to different places and use different certificates.
7. Is the host or CDN having an outage? Providers publish status pages. If your host or CDN reports an incident, you can stop investigating.

Step 3: Clear stale local data

Your computer remembers DNS answers for as long as their TTL allows, and a wrong or old answer can stick after the real records change. Flushing the local cache is harmless.

Also restart the browser afterwards, because browsers keep their own short-lived DNS cache. If you changed DNS yourself in the last day or two, remember that other people may still see the old answer until the old TTL runs out; a record with a 3600-second TTL can take up to an hour to disappear from resolvers that cached it just before the change.

If it is your own site

Run through the causes that owners miss most:

• Domain expired. Registrars park an expired domain, and the site simply stops resolving or shows a registrar page.
• Certificate expired. Common, entirely preventable, and now more likely because lifetimes are shorter.
• DNS records changed or deleted during a provider or e-mail change, often the A record or a CNAME.
• Hosting suspended for an unpaid invoice or a resource limit.
• Firewall or security plugin blocking a country, a network or your own address.
• Only one of www and the bare domain configured.

Compare what DNS returns with where you think the site is hosted. If the A record points at an address your host no longer uses, the site vanishes the moment the old server is switched off.

What a single check cannot prove

Every outside check runs from one place on one network. A public tool that tests from its own server, such as Down For Everyone Or Just Me, can say how the site looks from there; it cannot see a regional outage, a block by your provider, or a problem that only appears for logged-in users. The checker on this site runs from your own browser, which makes it better at telling you about your connection and worse at telling you about the rest of the world.

If three different paths all say the site works and yours does not, the fault is local. If two networks fail and your host's status page is quiet, open a ticket and include the exact error text, the time, and which checks passed. That detail gets you an answer faster than "my site is down".