Is it down for everyone, or just you? A five-minute diagnostic

You hit refresh on a site three times. Nothing. Is it down for everyone, or just you? The answer changes everything you do next — and most people skip the diagnostic step entirely and jump straight to restarting their router.

That's expensive. Restarting the router clears every signal you would have used to diagnose the actual cause. By the time you're back online, the only thing you know is that whatever was wrong is either gone or still broken — and you can't tell which.

There's a clean three-way split that resolves almost every "is it down" question. Run through it in order and you'll know within five minutes whether the problem is the site, your network, or your device — and you'll have collected enough evidence along the way to file a useful support ticket if the answer turns out to be on the vendor's side.

1. Probe the site from somewhere that isn't you

The first move is always the same: check the site from a vantage point that isn't your own computer. The reason is straightforward — if you only have your own browser's verdict, you can't separate "the site is down" from "my path to the site is broken." A third-party probe gives you an independent second opinion.

If the probe says the site is up, you know the issue is somewhere between your device and the public internet: your Wi-Fi, your ISP, your DNS resolver, a corporate proxy, a misbehaving browser extension, or a stale cache. If the probe also fails, the site is genuinely unreachable — for you and for a server in another country — and you can stop debugging your own setup.

Our Website Down Checker runs the probe from our infrastructure, not your browser. It reports:

• DNS resolution — whether the domain even points anywhere. A domain in clientHold or pendingDelete won't resolve from anywhere, even if it worked yesterday.
• The HTTP status code — 200 means the server is alive and answering. 403, 502, or 521 each tell you a very different story (see DNS vs SSL vs HTTP errors).
• The redirect chain — sites that redirect through three or four hops to reach a final URL sometimes break at any one of those hops. The probe walks the whole chain and shows each step.
• Certificate validity — an expired TLS certificate looks like a hang in most browsers. The probe surfaces certificate-expiry dates and chain errors directly.
• The resolved IP's hosting provider — useful when a major cloud region is having problems and you want to know whether the site you're trying to reach is on it.
• The domain's registration state — registrar-side problems like clientHold are invisible from a normal browser but obvious from a WHOIS lookup. We surface both.

2. Check the official status page

If the third-party probe also fails — or if the probe passes but something about the site is clearly degraded — the next step is the vendor's own status page. Most major providers publish a Statuspage.io-style feed (you'll see the familiar five-state vocabulary: operational, minor, major, critical, maintenance). They post incident updates faster than user-report aggregators and they're authoritative on what the vendor is willing to admit publicly.

Two things to remember when reading a status page:

1. Pages lag real incidents. Five minutes is the floor; an hour is common for partial outages. If you see errors and the page says green, you're almost certainly inside the lag window. See why official status pages sometimes lag behind real outages for the structural reasons.
2. "Operational" doesn't mean "working for you." It means "no component alarm has fired." Account-specific bugs, regional CDN failures, and feature-flag rollouts all fail invisibly from a global-aggregate view. See what 'degraded performance' means on a status page for the full taxonomy.

Every service status page on StatusDetector shows the vendor's official indicator alongside our own probe data and recent user reports. When the three signals agree, the answer is clear. When they disagree, the truth is usually closer to whichever signal is showing red — and the disagreement itself is useful information you can attach to a support ticket.

3. Test your own network in isolation

If the probe passes but you still can't reach the site, the issue is local. The fastest way to confirm is to switch networks: enable mobile hotspot from your phone (cellular data, completely separate from your Wi-Fi) and try the site over hotspot. If it loads on hotspot, the problem is somewhere in your home setup — your Wi-Fi, your router, your ISP, or your DNS resolver — not the site.

Once you've confirmed it's local, work through the order of suspicion:

1. Browser cache. Open an incognito or private window. This rules out cached error pages, stale assets, and a misbehaving service worker. About a quarter of "the site is broken" reports resolve here.
2. Browser extensions. Disable ad-blockers, privacy extensions, and any new extension you installed in the last week. Some CDN-tuning extensions inject headers that get sites rate-limited. Try the site in a different browser as a faster shortcut.
3. DNS resolver. Switch to 1.1.1.1 or 8.8.8.8 at the OS level. This rules out a misbehaving ISP resolver — one of the more common silent failures, especially for sites that have recently moved hosting providers and are caching stale records. Our DNS Lookup tool lets you query multiple resolvers side-by-side so you can see whether one of them is returning a different answer.
4. VPN. Turn off any VPN extension or system VPN. Sites behind anti-bot CDN rules (Cloudflare, Akamai, Imperva) sometimes refuse known VPN exits. If the site loads with VPN off and fails with it on, it's the VPN's exit IP being filtered — not the site.
5. Router. Restart it. This is the last step, not the first. If the site loads after a router restart, you've lost the diagnostic context, but the symptom is gone — and that's usually enough.

The shortcut

Three steps, in order: third-party probe, official status, isolate your network. The Website Down Checker collapses steps 1 and 2 into a single page. Step 3 you do on your phone in about 30 seconds.

Most "the internet is broken" moments resolve at step 1 — and most of the rest resolve at step 2 with a five- to fifteen-minute wait for the status page to catch up. Step 3 only matters when the answer is "it's local to you," which is the case in roughly a third of reports.

If you've worked through all three steps and the site is still unreachable, the next move is to write a useful report — see what to do before reporting an app outage for the kind of evidence support teams actually want. The five minutes you spent diagnosing is exactly the evidence that makes a support ticket land.

Frequently asked

What if mobile hotspot also fails?

Then the issue is either upstream of both your home network and your cellular carrier — a regional internet problem, a DNS provider outage, a CDN problem — or the destination really is down. Re-run the third-party probe; if it agrees, the site is genuinely unreachable from multiple paths, and waiting is the only fix.

Why does the same site sometimes work for my colleague but not me?

Three common reasons: (1) your ISP is routing through a different transit provider that has a path issue; (2) your DNS resolver is returning a stale or geographically different record; (3) you're behind a CDN POP that's currently degraded. The fastest test is to share a screenshot of the Website Down Checker result — if it agrees with one of you, the other person's path is at fault.

Is `downdetector.com` a reliable signal?

For trending failures of major consumer services, yes — a sharp spike in user reports usually precedes the vendor's own status page by 10–30 minutes. For long-tail services, the volume is too low to be useful. We aggregate user reports alongside vendor feeds and our probes for exactly this reason; no single signal is reliable on its own.

How long should I wait before assuming a site is down for good?

Most real outages resolve within an hour. CDN and DNS incidents commonly clear in 15–30 minutes. Database or authentication outages can run 2–6 hours. A site that hasn't recovered in 24 hours is either permanently down or in a serious incident — check the shutdown radar for context.