The browser says it can't reach the site. You try again. Same result. A colleague says it works fine for them. Now the question shifts: is the site down, or is this your connection?
These two situations look identical from inside a browser. The answer changes what you do next. Here's how to tell them apart and what to do with each.
Down for everyone vs. just for you
A browser failing to load a site can mean several different things. Your local DNS resolver may have a cached record pointing to an old server IP. Your ISP's routing path to that server may have a problem specific to your network. The site's server may be down entirely. Or the site may be returning errors for everyone. From inside the browser, all of these look like a page that won't load.
The only way to distinguish between "the site is down" and "the site is unreachable from my network" is to check from a different network vantage point. That's what a status checker does: it sends an HTTP request from a server on a different network than yours and reports what it gets back.
If the checker reports the site as up but you can't reach it, the problem is between your machine and the site's server, not at the site itself. If the checker also fails, the site is down or unreachable at the server level.
What an online status checker actually does
When you submit a URL to the AT USE status checker, we send an HTTP request to that address from our server. We follow any redirects, measure response time, and report the final HTTP status code. The check is independent of your ISP, your browser, your DNS cache, and your location.
The result tells you two things: whether the URL is reachable at all (TCP connection succeeds), and what the server returned (status code, response time). A 200 means the server responded normally. A 5xx means the server responded with an error. A timeout means we couldn't connect at all.
We see patterns in the check logs worth knowing. About 60% of URLs that fail for a user come back as reachable from our server. That majority-case outcome points to a local DNS cache issue, an ISP routing problem, or a browser/proxy configuration. The remainder that we also can't reach split between full server outages, CDN failures returning Cloudflare-specific errors (521, 522, 524), and SSL handshake failures where the certificate has expired or been misconfigured.
Why websites go down
Most downtime falls into a small number of categories. Understanding which one you're looking at helps narrow what to do next.
Server overload. A traffic spike can exhaust the server's capacity. The server returns 503 (Service Unavailable) or simply stops responding. This type of outage is usually brief and recovers on its own once the spike subsides.
SSL certificate expiry. When the certificate expires, the server refuses HTTPS connections. Browsers show a certificate error page rather than a generic "can't reach" message. Unlike most other failures, this hits all users at the same moment and stays broken until the certificate is renewed.
DNS misconfiguration. If someone updated DNS records incorrectly, the domain may resolve to the wrong IP or to nothing at all. DNS problems can look different from different regions depending on which resolver each user's ISP queries. A WHOIS lookup confirms current nameservers and registrar status — useful when a recent domain transfer or nameserver change is suspected.
CDN origin failure. The CDN is running normally but can't reach the actual server behind it. Users get a Cloudflare 502 or 524 error. The CDN itself is up; the origin isn't.
Deployment failure. A code push breaks something server-side. PHP/Python/Node errors return 500. Missing configuration returns the same. Often specific to certain URLs or page types rather than the whole domain.
DNS delays vs. actual downtime
DNS propagation is not the same as a site being down, and the two are easy to confuse. When a domain's DNS records change (new hosting provider, new server IP, new CDN), the update takes time to spread through the global network of DNS resolvers. Your ISP's resolver holds a cached copy of the old record until its TTL (time-to-live) expires. That can take anywhere from a few minutes to 48 hours.
During propagation, some users reach the new server and some reach the old one (or get an error if the old server is gone). A status checker running from our server will report whatever its resolver currently sees for your domain. The result may differ from what you see locally.
To check whether you're looking at a DNS propagation delay: run a DNS lookup for your domain and compare the IP addresses returned by your resolver versus a known public resolver like 8.8.8.8. The DNS propagation checker queries multiple global resolvers simultaneously, showing which have picked up the change and which still cache the old record. If they differ, you're waiting for the cache to expire.
What to do when a site is down
Start with the status checker. Clear result in 2 seconds.
If it says the site is up and you still can't reach it: flush your local DNS cache (Windows: ipconfig /flushdns; macOS: sudo dscacheutil -flushcache), then try again. If that doesn't fix it, switch from WiFi to mobile data or from home to a mobile hotspot. If it works on a different network, the problem is specific to your ISP or router.
If the checker says the site is also down: wait 10 minutes and check again before escalating. Transient overloads and brief failovers often self-correct faster than it takes to file a ticket. If it stays down, check the site's status page (usually status.{domain}.com), their social media, or Downdetector for major platforms.
If it's your own site: open your hosting provider's dashboard first, not the site itself. Most hosts surface server alerts there before external monitoring catches them. Then check the most recent deployment and the most recent DNS change, in that order. These two causes account for most unplanned outages for small-to-medium sites. If email delivery has also stopped alongside the web outage, check your MX records — a nameserver-level misconfiguration can break both web and mail resolution at the same time.
What the status code means
200 OK. The server responded normally. The site is up.
301 or 302. A redirect. The checker follows these and reports the final destination's status code. If the destination returns 200, the site is up.
403 Forbidden. The server is running but refusing the request, either because of geographic blocking or IP-level rate limiting. The domain is responding; your specific access is blocked.
404 Not Found. That specific URL doesn't exist. The server is running; the page is not.
500 Internal Server Error. The server responded but encountered an application-level error. The domain is up; something in the application is broken.
502 Bad Gateway. A proxy or CDN can't reach the origin server behind it. Common in Cloudflare setups when the origin goes offline.
503 Service Unavailable. The server is intentionally rejecting requests, typically during maintenance mode or under active load protection.
521, 522, 524. Cloudflare-specific codes for origin unreachable, connection timeout, and response timeout respectively. All three indicate the CDN is running but the origin server behind it isn't responding.
The fastest path to an answer
Run a status check and read the code. Most “is it down” situations resolve in under 30 seconds with this information. If the site is up and you can't reach it, the problem is on your network side. If the site is down, wait before escalating. If you maintain the site and it's down, check the host dashboard and the deployment history before touching anything else.