Your browser stalls. The page spins and never loads. Before you start flushing caches and rebooting your router, it is worth figuring out whether the site is broken for everyone or just for you. The fix is completely different depending on the answer.
The Fastest Way to Find Out
Use the HTTP check tool. Paste the URL and the tool sends a real HTTP request from 50+ nodes spread across different countries. Within a few seconds you see status codes and response times from each location.
If most nodes return a 200 OK, the site is up — the problem is on your side. If nodes all time out or return 5xx errors, the site is genuinely broken.
This beats the old trick of asking a friend because one location is not enough. A site can be fully reachable in Germany while being network-unreachable from Southeast Asia.
What the Status Codes Mean
- 200 — the server responded normally.
- 301 / 302 — the server is up and redirecting. Usually fine.
- 403 — the server is up but blocking the request. Could be a WAF or geo-block.
- 500 / 502 / 503 — the server is reachable but something inside is broken.
- 0 / timeout — no response at all. Either the server is down or a firewall is silently dropping connections.
When the Problem Is on Your Side
A few common culprits:
Stale DNS cache. Your machine or ISP resolver cached an old IP for the domain. On Windows, run ipconfig /flushdns. On macOS, sudo dscacheutil -flushcache. Then try again.
ISP routing issue. Sometimes the link between your ISP and the destination network degrades or fails entirely. The site is reachable from everywhere else, just not through your provider. Switching to mobile data (bypassing your home network) is a quick test.
Corporate firewall or content filter. Some office networks and parental control tools block sites by category. Try from a personal device on a different network.
IPv6 misconfiguration. If your device prefers IPv6 but your ISP has a broken IPv6 path, connections silently fail. Disabling IPv6 temporarily can confirm this.
When the Site Is Actually Down
If the HTTP check shows failures across most global nodes:
Application crash. The web server ran out of memory or hit an unhandled error. Check your server logs. A 502 from a reverse proxy usually means the backend process is dead.
Database down. Dynamic sites fail with a 500 error when the database is unreachable. Static assets might still load from cache while PHP or Node throws errors on every request.
Expired TLS certificate. Your browser rejects it before even connecting. The HTTP check shows this as a 0 or SSL error. Renewing the certificate (or enabling auto-renewal via Let's Encrypt) fixes it immediately.
CDN or DNS misconfiguration. If you recently changed DNS settings, some users might still be hitting old servers while others get the new ones. The DNS propagation checker shows which regions have picked up your new records.
Sanity Check: Run a Ping First
Before the HTTP check, a quick ping tells you whether the server is reachable at the network layer at all. If ping succeeds but HTTP fails, the machine is alive but the application is broken. If ping also fails from most locations, the machine itself is down or network-unreachable.
Checking a Specific Port
If your application runs on a non-standard port (8080, 8443, 3000), use the TCP check to verify the port is open and accepting connections — separately from the HTTP response. A port can be firewalled even when the server itself is up.