Blog
A practical check sequence to tell a local DNS, ISP or browser issue from a real outage, read multi-country results correctly and decide when to open an incident.
To find out whether a website is down for everyone or just me, request the same URL from several independent networks and countries and compare the results with what you see locally. If remote locations get a normal response while your machine fails, the problem sits in your DNS cache, ISP route, VPN or browser. If most locations fail the same way, it is a real outage and you should start treating it as an incident.
This guide gives you a fixed check sequence with commands, explains how to read multi-location results, including the confusing partial cases, and ends with a concrete rule for when an engineer's hunch becomes an incident.
A failed page load in a browser hides where the failure happened. Between your laptop and the origin server there are at least five layers that can break independently:
Only the last layer is guaranteed to affect every user. Everything above it can fail for one person, one city or one ISP while the service is healthy for everyone else. That is why you need an outside view before you page anyone.
After a DNS change, your machine or resolver may still hold the old IP until the TTL expires. Symptoms: other people can reach the site, you get connection refused or a timeout, and the IP your system resolves differs from what a public resolver returns.
A broken route between your ISP and the hosting network produces timeouts for everyone on that ISP, while users on other networks are fine. Switching to a mobile hotspot is the fastest way to confirm this.
Cached redirects, HSTS entries, stale service workers, a misbehaving extension or a forced proxy setting can break a single browser while curl on the same machine works. If curl succeeds and the browser fails, the network is not your problem.
Corporate networks often block new domains, inspect TLS or route traffic through a region where your CDN behaves differently. Turning off the VPN or testing from outside the office network separates this quickly.
A WAF or rate limiter can return 403 or 429 to your IP only, often after you ran load tests or scripts against the site. Remote locations will see 200 while you see an error.
Run these steps in order. Each one rules out a layer, and most investigations end within the first four.
curl -sS -o /dev/null -w "code=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.comdns points to resolution, a hang before connect to the network path, a failure before tls to certificates or SNI, and a 5xx code to the application.dig +short example.com
dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux with systemd-resolved
resolvectl flush-cacheschrome://net-internals/#dns.curl -sS -o /dev/null -w "%{http_code}\n" --resolve example.com:443:203.0.113.10 https://example.commtr -rwc 50 example.comopenssl s_client -connect example.com:443 -servername example.com -briefA multi-location check returns a status and a latency per region. The pattern matters more than any single result.
The problem is local. Go back to steps 2 to 5: DNS cache, VPN, ISP route or a block on your IP. There is no outage to communicate, though if colleagues on the same ISP see it too, customers on that ISP may as well.
This is a real outage. Look at how they fail. Identical HTTP 5xx responses mean the network and edge are fine and the application or its dependencies are broken. Timeouts everywhere point to the origin, the load balancer or the hosting network. DNS failures everywhere point to your authoritative nameservers or an expired domain.
This is the case people underestimate. A failure in one or two regions is not "just me" - it is a partial outage for every customer whose traffic takes that path. Typical causes are a degraded CDN point of presence, an anycast DNS node returning bad answers, a regional routing incident, or a WAF or geo rule that is stricter than intended. Compare the response codes: timeouts suggest network or edge problems, while 403 from some regions only suggests a rule.
A DNS change is still propagating, or different CDN edges serve different versions of a deploy. Not an outage by itself, but worth watching if old IPs point to infrastructure you already shut down.
Not down, but degraded. If time to first byte in one region is several times higher than elsewhere, users there experience the site as broken even though checks are green.
A single round of requests can catch a brief network blip. Before declaring an outage, repeat the multi-location check once or twice over a minute or two. A failure that shows up consistently from several independent locations is solid evidence. A failure that appears once from one probe and then disappears is noise.
This is the same reasoning that well-configured monitoring uses to avoid paging people for nothing. If your alerts are firing on exactly these blips, the guide on reducing false positive alerts with multi-region checks and retries covers the alerting side in detail. This article is about the manual investigation when someone asks "is it down?"
Once you know the outage is real, the next decision is whether it deserves an incident. A practical rule that small teams can apply without debate:
The first update can be short: what is affected, where, and when you will update next. For wording at each stage, see how to write an incident status update. Include the multi-location findings in your internal notes, because "fails from Frankfurt and Singapore, works from Virginia" narrows the search for whoever investigates next.
The manual sequence is useful when you are already suspicious. The better position is to know before anyone asks. Continuous checks from several regions run the last step of the sequence on a schedule and only alert when multiple locations agree.
m0nitor is one option for this. Its uptime monitoring runs HTTP(S), TCP, ping, DNS and SSL certificate checks from distributed probes in several regions and confirms an outage from multiple locations before an alert fires. You can get the same effect with other tools or self-hosted probes in different networks, as long as the probes sit outside your own infrastructure and a single location cannot trigger a page on its own.
Request the URL with curl from your machine, then check it from several external locations in different countries. If external locations succeed and you fail, the cause is local, usually DNS cache, VPN, ISP routing or a block on your IP. If most locations fail, the site is actually down.
The most common causes are a stale DNS cache after an IP change, a routing problem at your ISP, a VPN or corporate proxy, browser state such as cached redirects or service workers, and a WAF or rate limit that blocked your IP. Testing with curl over a mobile hotspot separates most of these within minutes.
Yes. A degraded CDN edge, a faulty anycast DNS node, regional routing problems or geo-blocking rules can make a site unreachable in some regions while it works elsewhere. For users in those regions, it is a real outage and should be handled as one.
Only if the problem is a stale cached record on your machine. Compare the IP from your resolver with the answer from a public resolver like 1.1.1.1. If they match, flushing will not help and the cause is further along the path or on the server.