Down for everyone, or just for you? A sixty-second answer

Before you message the host, before you open a ticket, before you tell a client their site is down, you need to know whether the failure is theirs or yours. It takes a minute and most people skip it, which is how a hosting provider ends up with a support queue full of hosts-file entries.

The fastest reliable test is not incognito mode. It is another network entirely: turn off wifi on your phone and load the site over mobile data. Different resolver, different route, different device, no shared state with your laptop. If it works there, stop looking at the server.

The nine local causes, and two survive incognito

Private browsing clears cookies and history. It does not clear the things that matter here.

The last row deserves attention, because it is an agency problem specifically and it feels like gaslighting when it happens. You have been testing a client's site. Twenty reloads, a few form submissions, some URLs that do not exist. A security plugin or a WAF reads that as an attack and bans your office address, usually silently and usually for hours. The site is now down for your whole team and up for the entire world, and everyone in the office confirms each other's diagnosis.

The IPv6 row is the other one that produces two honest people disagreeing. A domain has an AAAA record pointing at an address that no longer serves anything. Browsers try both families and use whichever answers first, so they hide it. A probe or a terminal that resolves AAAA first gets a refusal. The mechanics, and why a refusal is more informative than a timeout, are in connection refused.

The sixty seconds, in order

curl -sS -o /dev/null -w 'code %{http_code}  ip %{remote_ip}  dns %{time_namelookup}  ttfb %{time_starttransfer}\n' \
  https://example.com/

One line, four answers. The status code, the address actually used, how long resolution took, and how long the server took to start replying. If the address is not the one you expect, the rest of the investigation is about DNS and nothing else.

Then, if that fails, the same request from mobile data or from any machine outside your network. Then, if you want to know whether a specific server is healthy while ignoring DNS entirely:

curl -sSI --resolve example.com:443:203.0.113.10 https://example.com/

That connects to the address you name while presenting the real hostname, so virtual hosting and SNI behave normally. It is the difference between "the site is down" and "the DNS points at the wrong box", which are two different tickets sent to two different people.

The reverse case, which is worse

Sometimes the site is down for everyone and up for you. This is more dangerous, because you will confidently tell the client they are mistaken.

Three causes. A service worker is serving a cached copy of the site from your browser's storage, and it will keep doing so indefinitely. Your hosts file still points at the new server from a migration you finished last month, so you are the only person on earth reaching the working machine. Or you are logged in, and a caching layer bypasses the cache for authenticated sessions, so you see a freshly generated page while anonymous visitors are served a broken cached one.

That third one is common on WordPress with any page cache, and it has a specific signature: the client sends a screenshot of something you cannot reproduce, and everything you try works. Log out, or open the site in a browser you never use, before you tell anyone they are wrong.

Third-party checkers and status pages

Public "is it down" services are useful for the geography question and for nothing else. They tell you a handful of probes could or could not reach the address. They do not know what the page is supposed to contain, so a site serving an empty template, a database error at 200, or last month's staging copy reads as perfectly fine. That gap, layer by layer, is what a status check actually measures.

Provider status pages are worth checking and worth distrusting on timing. They are updated by people, after the incident is confirmed internally, which means they are reliably behind the failure and occasionally behind it by hours. A green status page is not evidence that your client's server is fine. It is evidence that nobody has written the update yet.

What to send the client, and when

Send something within a few minutes, and make it specific, because the alternative is silence while you investigate and silence is what damages the relationship.

Three sentences do it: what is failing, from where you have confirmed it, and what you are doing next. "The site returns a gateway error from three networks, the server is reachable but the application is not responding, I have opened a ticket with the host and I will update you within the hour." That is a completely different message from "we are looking into it", and it takes the same thirty seconds to write once you have run the commands above.

The part that gets missed: say when you will next write, and then write then, even with nothing new. A client who hears from you every hour will wait. A client who hears nothing starts phoning, and answering the phone is time you are not spending on the outage.

One thing not to put in that message: "the server responds to ping". It is the reflex under pressure and it means less than it sounds like, because the address answering an echo request and the software serving the site are two different things on two different layers. A host can answer every ping you send while the site is entirely gone, and telling a client the server is fine on that basis is a claim you will have to walk back.

If you want a second opinion from outside your network without setting anything up, run the address through the checker here. It reads the body as well as the status, which is the part that matters when the page answers 200 and is still wrong.