Is It Down or Is It Just Me? How to Diagnose an Outage in Five Minutes

When a site won't load, the cause is somewhere on the path between your device and the site's server. The fastest way to find it is to check each layer in order, starting with the one closest to you:

1. Your own connection.
2. DNS — can the name be turned into an address?
3. The network path — can you reach that address?
4. The server — does it answer, and with what?
5. The provider — is there a known incident?

Each step takes under a minute, and each one either finds the problem or rules out a whole category of causes.

Open two or three unrelated, very reliable sites. If none load, the problem is your connection, router or ISP, not the site you were trying to reach.

If other sites work, check two things that commonly break only some sites:

• VPN, proxy or corporate network. Disconnect the VPN and try again. Corporate networks and some VPNs block or reroute specific services.
• Your public IP. The IP lookup shows the address and network sites see you coming from. If it shows an unexpected country or a hosting provider, a VPN or proxy is still active, and the site may be blocking that network.

Then try the site from a different network — your phone with Wi-Fi off is the easiest. If it works on mobile data but not on your home connection, the issue is between your ISP and the site.

A site can be perfectly healthy while its name doesn't resolve. Ask your own resolver, then two public ones:

$ dig example.com +short
$ dig @1.1.1.1 example.com +short
$ dig @8.8.8.8 example.com +short

(On Windows, use nslookup example.com 1.1.1.1.)

How to read the result:

• Public resolvers answer, yours doesn't: your ISP's or router's resolver is the problem. Switch to a public resolver while it's fixed.
• No resolver answers, or all return SERVFAIL: the site's DNS is broken — an expired domain, a DNS provider outage, or a DNSSEC failure. If dig +cd succeeds where plain dig gets SERVFAIL, it's DNSSEC; see the DNSSEC guide.
• Different resolvers return different addresses: often normal (CDNs and GeoDNS return different answers by location), but during a migration it means some resolvers still have the old record cached.

The DNS Propagation Checker asks several public resolvers at once and shows their answers side by side, and the DNS Lookup shows every record type for the domain. In the October 2025 AWS outage, this step would have shown the problem immediately: the DynamoDB endpoint's name simply had no addresses. See what recent cloud outages had in common.

If the name resolves, check whether the address is reachable:

$ ping -c 4 203.0.113.10
$ traceroute 203.0.113.10        # tracert on Windows; mtr is better if installed

Many servers and firewalls drop ping, so no ping reply on its own means little. Traceroute is more useful: if hops stop responding at your ISP's network, the problem is local; if they stop several networks away, the problem is on the internet path or at the destination's provider.

For a web server, test the port directly — this is what actually matters:

$ nc -zv example.com 443
Connection to example.com port 443 [tcp/https] succeeded!

"Connection refused" means the host is up but nothing is listening; a timeout means a firewall is dropping traffic or the host is unreachable. The Port Checker runs the same test from outside your network.

Large routing problems — like the February 2026 Cloudflare incident, where address ranges were withdrawn from BGP — show up in public routing tools. RIPEstat shows whether an IP prefix is currently visible on the internet, and Cloudflare Radar's Outage Center tracks country- and network-level disruptions.

If you can connect, look at what comes back:

$ curl -sI https://example.com
HTTP/2 503
server: cloudflare

The status code tells you a lot:

The server header shows who answered. If a CDN answers with an error, the CDN is reachable — the failure is behind it, at the origin or inside the CDN itself.

Also check the certificate. An expired or mismatched certificate makes browsers show a full-page warning that looks like an outage. The SSL Checker shows the expiry date and the chain.

By now you usually know where the problem is. Confirm it:

• The service's official status page — but remember status pages often lag behind reality by 15–30 minutes, and some go down with the service.
• The status pages of the providers underneath it. If the site is behind Cloudflare, check Cloudflare's status; if it's on AWS, check the AWS Health Dashboard.
• Other users. Reports on social media and community sites appear within minutes of a large outage, often before any official acknowledgement.

If everything points to your side — your resolver, your ISP's route — contact your ISP with the traceroute output. If it's the site, there's nothing to do but wait; clearing your browser cache or restarting your router won't help, and it can make things worse by throwing away cached DNS that still works.