Is it down for everyone, or just you?

There is one question underneath every "is X down" search, and it is not really about the website. It is: Do I need to fix something, or do I need to wait? Those are completely different afternoons, and almost every troubleshooting guide answers them in the wrong order.

The fastest route to an answer is not to check your Wi-Fi, restart your router, or clear anything. It is to find out whether a machine that has nothing to do with you can reach the site.

Step one: Check from somewhere that is not you

A browser tells you almost nothing about why a request failed. The same grey page appears when the origin server has crashed, when your ISP's DNS resolver returned garbage, when an extension blocked the request, and when a captive portal in a hotel silently swallowed it. Local tests cannot distinguish those, because they are all local from your machine's point of view.

A check from a different network can. If an independent server on a different continent, using a different resolver and a completely different route, gets a normal response from the site, then the site is working and the fault is between you and it. If that independent server cannot reach it either, there is nothing on your side to fix.

That is the whole reason the checker on this site exists, and it is why the result page reports each stage separately rather than just succeeding or failing. Knowing that a request died at DNS rather than at the TCP connection narrows the problem enormously before you have touched anything.

If the outside check succeeds: It is you

The site is fine. Work through these in order, because they are sorted by how often each one turns out to be the answer, not by how technical they sound.

1. A stale DNS answer

Your machine, your router and your ISP all cache the translation from a domain name to an IP address. If a site has moved and the old answer is still cached somewhere in that chain, you will keep being sent to an address that no longer serves it. Flushing your local DNS cache and, if that fails, pointing the device at a public resolver resolves this in under a minute. The DNS guide covers exactly how.

2. A cached broken page

Modern sites install service workers that can serve a stored copy of a page offline. When that stored copy is the broken one, a normal refresh will happily give it back to you. A hard reload - Ctrl+Shift+R, or Cmd+Shift+R on a Mac - Bypasses it. Trying the site in a private window is the faster version of the same test, because private windows start with no cache, no service worker and no cookies.

3. An extension

Content blockers break more sites than their users realise, particularly when a site changes its analytics or CDN provider and a filter list has not caught up. A private window usually runs without extensions, which is why it is such a useful single test: It clears cache, cookies and extensions in one action.

4. A VPN, proxy or corporate network

A VPN puts your traffic on someone else's IP address, and that address may be blocked, rate limited or geographically wrong for the service you are using. Corporate networks add TLS inspection and content filtering that break some sites outright. Disconnecting the VPN for one test is decisive.

5. The account, not the service

If you can reach the site but cannot sign in, and other people can, consider that the problem may be specific to your account - A security hold, a rate limit, or a session that needs clearing. This is invisible to every outage tracker on the internet, including this one.

If the outside check fails too: It is them

Now stop touching your own equipment. Nothing you do locally will help, and the useful question becomes how long this is likely to last. Where the check failed tells you a surprising amount.

• The name did not resolve. The problem is the domain or its nameservers, not the web server. This is either a DNS configuration mistake, an expired domain, or - In the dramatic cases - A routing withdrawal that has removed the nameservers from the internet entirely. This class of failure tends to last longer than a crashed server, because the fix has to propagate.
• The connection was refused. The name resolved and something answered, but there is nothing listening on that port. Usually a service that has stopped, or a firewall rule that was just applied.
• The connection timed out. Packets are going somewhere and nothing is coming back. This is the classic overload signature: The server is up, the queue is full, and requests are being dropped. These often resolve on their own within minutes as load sheds.
• A TLS error. The server is alive and answering, but its certificate is expired or misconfigured. Almost always a short outage with an embarrassing cause, and it is fixed the moment somebody notices.
• A 5xx status. The server answered and told you it failed. A 502 or 504 means a proxy could not reach the application behind it; a 503 often means deliberate load shedding or maintenance.

The case everybody gets wrong: It is up, and it is broken

The most common shape of a large outage is not a dead website. It is a website that loads perfectly and does not work. Login fails, the feed is empty, messages will not send, checkout errors at the last step. Every automated monitor on the internet will report that service as healthy, because the home page returns 200 in 400 milliseconds.

This is why user reports matter and why this site shows them next to its own measurements rather than instead of them. A probe is precise and narrow. A crowd is vague and broad. When the probe says up and the reports chart is vertical, the answer is almost always a partial failure - And partial outages have their own article because they behave so differently from the total kind.

What not to bother doing

Three pieces of standard advice that mostly waste time:

Restarting your router first. It fixes a real but narrow class of problem, takes three minutes, and disconnects everyone in the house. Do the outside check first; if the site is genuinely down, you have rebooted your router for nothing.

Clearing all browsing data. An enormous hammer that signs you out of everything you use. A private window tests the same hypothesis and costs nothing.

Reinstalling the app. Almost never the answer during an outage, and on some services it will lose local data - Snapchat Memories that were never uploaded being the notorious example. Confirm the platform is healthy before you delete anything.

Putting it together

Check from outside. If it works out there, fix your side in the order above, starting with DNS and a private window. If it does not work out there, note where the request died, check whether the provider has a status page we link to, and then wait - Because that is genuinely the correct action, and the only thing more frustrating than an outage is spending it reinstalling software that was never broken.