You open Discord, and nothing loads. Before you start restarting your router or reinstalling the app, there is one thing worth knowing: the problem might have nothing to do with you.
Websites go down all the time — for minutes, sometimes hours. But from where you are sitting, a global outage and a broken DNS cache on your own laptop look identical. Both are a blank screen and a spinning tab. This guide is about telling them apart quickly, and then fixing the right thing.
The 60-second version
If you only have a minute, do these three things in order:
1. Run a server-side check on the domain. That answers "can anyone reach this server right now" independently of your machine.
2. If the check says the site is UP but you still cannot load it, the problem is between you and the server. Try the site on mobile data with Wi-Fi turned off. That single test rules out your home network, your router, and your ISP in about ten seconds — if it works on cellular, the fault is on your local network.
3. If the check says the site is DOWN, stop troubleshooting. Nothing on your device will fix someone else's server. Check their official status page and wait.
Everything below is the longer explanation of why those three steps work, and what to do when the answer is not clean.
What a server-side check actually proves
When you run a check on WebsiteDown, we send an HTTP request from our own infrastructure to the target server. That request never touches your browser, your ISP, your local DNS cache, or your VPN. It is an independent second opinion.
If that request fails — timeout, connection refused, a 5xx response — the site is unreachable from our vantage point too, and the problem is almost certainly not you.
If the request succeeds, we know the server answered someone. It does not prove the server will answer YOU, because your path to it is different from ours.
Be precise about what this does not prove. We run one HTTP probe from one serverless region per check. A successful probe means the site was reachable from that region at that moment — not that it is healthy for every user on earth. That is why the next signal matters.
The awkward middle: not you, but not everyone either
A large share of real outages are partial. A CDN edge fails in one region. A mobile carrier's routing breaks. A login service goes down while the marketing homepage stays perfectly up. In every one of those cases a single probe from a US data centre reports a cheerful 200 OK while thousands of people cannot use the product.
This is why we pair the probe with community reports. Anyone can press "Report issue" or "It's working for me" on a status page, and those reports are aggregated into 15-minute, hourly, and daily windows.
When our probe succeeds but reports spike, we do not call it an outage and we do not call it fine. The verdict says "likely regional or partial issue" — which is the honest description of exactly that evidence. Mixed signals, where some people report failures and others confirm it works, read the same way. If you see that verdict, the answer to "is it just me" is: no, but it is not everyone either.
When the check says UP but you still cannot load it
This is the interesting case, and there is a right order to work through it. Go from the layers that break most often to the ones that rarely do.
DNS is the usual suspect. Your device asks a resolver to turn a domain name into an IP address. If that resolver has a stale or poisoned answer, you get errors while everyone else is fine. Symptoms: the browser says the server cannot be found, or you land somewhere unexpected. Try loading the site on a device using a different network — if it works there, suspect DNS. Flushing your DNS cache or temporarily switching to a public resolver will confirm it.
Your ISP or the route to the server. Networks occasionally lose specific routes while the rest of the internet is unaffected. The mobile-data test above is the fastest check: same site, completely different network path.
VPN, proxy, or corporate network. A VPN exit node can be blocked by the site, rate-limited, or geographically misrouted. Corporate networks and school Wi-Fi frequently block categories of sites outright. Disconnect the VPN and retry. If a site works without the VPN, it was never down.
Browser cache, extensions, and service workers. Modern sites install service workers that cache pages aggressively; a bad cached bundle can produce a blank page on an otherwise healthy site. Try a private window first, since that disables most extensions and bypasses the cache. If the private window works, clear the site's data.
Your device clock. This one is rare but genuinely baffling when it happens. TLS certificates are valid for a time window, so if your system clock is badly wrong, every HTTPS site starts throwing certificate errors. If suddenly nothing secure loads anywhere, check the date.
Geo-blocks and government restrictions. Some sites refuse traffic from entire countries, and some countries block sites at the ISP level. Our probe runs from outside your network, so it will happily report the site as reachable while your local ISP refuses to route you there. If a site is up for us, up on a VPN, and down on your normal connection, this is the likely explanation.
Checking from somewhere that isn't you
The strongest evidence that a problem is local is watching the same site respond fine from several other places at once.
Our speed test includes a free preview that measures a domain from five region-pinned edge locations — US East, US West, EU/London, Tokyo, and Hong Kong — and reports reachability and round-trip latency from each. It is a few checks a day at no cost and no account needed.
If all five regions reach the site and you cannot, the fault is in your local stack and the section above is your checklist. If several regions fail, it is not you. If some regions succeed and others fail, you are looking at a genuinely regional problem — worth screenshotting if you are reporting it to the vendor, because "it is down from Tokyo but fine from London" is dramatically more useful to an engineer than "your site is broken."
When it really is down for everyone
Once you have established the site is globally unreachable, the useful moves are narrow, because you cannot fix someone else's infrastructure.
Check the vendor's official status page. It is authoritative when it says something is wrong. It is also usually behind reality — a human has to confirm the problem, decide to publish, and write the notice, while community reports start the instant users hit errors. A quiet status page early in an incident is not evidence that nothing is wrong.
Set an alert instead of refreshing. Refreshing a dead site in a loop is the least productive thing you can do with an outage. Ask to be emailed when it recovers and go do something else.
If other people depend on you knowing, share the check result rather than your opinion. A timestamped verdict with the probe evidence and report counts ends the "works for me" argument much faster than a screenshot of a blank tab.
If it is your own site that is down, the picture changes: now you want to know which layer broke. Our checks separate DNS resolution, TLS handshake, and the HTTP response, so an expired certificate reads as an expired certificate rather than a generic failure.
The order to try things, in one list
Save yourself the guesswork next time:
1. Run a server-side check on the domain. Down? Stop and wait. 2. Up, but broken for you? Load it on mobile data with Wi-Fi off. 3. Still broken? Open a private window to rule out cache, extensions, and service workers. 4. Still broken? Disconnect any VPN or proxy and retry. 5. Still broken? Flush your DNS cache or switch resolvers. 6. Still broken? Check your system clock, then try another device on the same network — that separates "this machine" from "this network". 7. Working everywhere except your normal connection? Suspect an ISP-level block or geo-restriction.
Most problems resolve by step three. The value of the sequence is that each step eliminates a whole layer, so you are never guessing twice about the same thing.