Between typing an address and seeing a page, roughly six things have to work. When any one of them fails, the browser shows something that looks identical to the site being offline. That is why so much of reported downtime is not downtime.
The chain, in order
- DNS. The name is translated into an IP address.
- Routing. Packets find their way across networks to that address.
- TLS. An encrypted connection is negotiated and certificates are validated.
- Edge. A CDN or proxy accepts the request.
- Origin. The actual web server responds.
- Application. Code and database produce the page.
Only the last two are “the website” in the way most people mean it. The first four fail independently and account for the majority of apparent outages.
The four impostors
DNS caching. When a site moves servers, the old address stays cached on your machine and at your ISP until the record’s time-to-live expires. During that window the site is live for other people and dead for you. Nothing is wrong with the site; you are being sent to an address that no longer serves it.
Your own DNS resolver. ISP resolvers fail, and when one does, every site appears down at once. The tell is exactly that: not one site, but all of them, while the connection itself still works.
Certificate expiry. A lapsed certificate produces a full-page browser warning that most people read as “this site is broken”. The server is running perfectly and serving content; the browser is refusing to show it. A device with a badly wrong system clock produces the identical warning on sites with perfectly valid certificates.
Edge failure. When a CDN has a regional problem, the origin is healthy and unreachable through the edge. Visitors in one region see nothing while the rest of the world is unaffected — which is why an incident at a major provider such as Cloudflare produces thousands of simultaneous reports about thousands of unrelated sites.
Why two people disagree about whether a site is up
| Cause | Who sees the failure |
|---|---|
| Stale DNS cache | Only people whose cache has not expired |
| Regional CDN problem | One geography |
| Partial deployment | Whoever lands on the bad servers |
| Rate limiting | Heavy users and shared IP addresses |
| Geo-blocking | Specific countries, permanently |
| IPv6 misconfiguration | Only IPv6 users — a classic silent failure |
How external checking resolves the argument
A monitoring service requests the site from several networks in different places and reports what each one received. That removes your DNS, your cache, your ISP and your browser from the question entirely. Understanding how downtime checks work is worth two minutes, because it also explains the limits: a check that receives a 200 response has proved the server answered, not that the page rendered correctly or that logging in works.
This is why status pages can show green during a real incident. The automated check passes; the thing users actually do does not.
A ninety-second triage
Different browser, then mobile data, then an external check. Those three, in that order, correctly classify almost every case: browser-level problem, network-level problem, or genuinely down. Only after all three point at the site itself is there any reason to start reporting an outage — or, if it is your own site, to start waking people up.