Website Down or Just Me? How to Check in 30 Seconds

A site will not load. Before you clear your cache, reboot the router, or file an angry support ticket, answer one question: is the site down for everyone, or just for you? The answer changes everything you do next — and you can get it in under thirty seconds.

Step 1: test the site from outside your network

Your browser failing proves nothing by itself — the problem could be your DNS cache, your ISP, your VPN or the site itself. Run the URL through our Website Uptime Checker: it requests the site independently and reports the HTTP status code, response time and any redirect chain.

• Status 200 with a normal response time → the site is up; the problem is on your side. Skip to step 3.
• Status 5xx or a timeout → the site (or its hosting) is genuinely down. Nothing on your end will fix it; check back later or look at the service’s status page.
• Status 4xx → the site is up but that specific page is the issue (404 = page gone, 403 = you are blocked or need auth, 429 = you are being rate-limited).

Step 2: understand what the status code is telling you

Code	Meaning	Whose problem
200	Site responded fine	Yours (local/network)
301/302	Redirecting — follow the chain	Depends where it lands
403	Forbidden — blocked, geo-fenced or auth required	Mixed
404	Page does not exist (site itself is up)	The link
429	Too many requests — rate limited	Temporary
500/502/503	Server error / bad gateway / overloaded	The site’s
Timeout / DNS failure	Server unreachable or domain misconfigured	The site’s (usually)

A redirect loop (endless 301s) and an expired TLS certificate are two classic “up but broken” states the checker also exposes — the server is technically running, but no browser will show the page.

Step 3: if it’s just you, fix the local suspects in order

1. Try another network. Switch your phone to mobile data and open the site. Works there? Your Wi-Fi/ISP is the issue.
2. Flush DNS. Windows: ipconfig /flushdns · macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Stale DNS is the most common “just me” cause after a site migrates hosting.
3. Switch DNS resolvers. Set your DNS to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) — ISP resolvers are often slow to pick up changes.
4. Bypass extensions and VPN. Ad blockers, privacy extensions and corporate VPNs silently block domains; test in a private window with the VPN off.
5. Clear the site’s cookies/cache — a corrupted cached redirect can wedge one specific site while everything else works.

For site owners: monitor before your users notice

If the site in question is yours, ad-hoc checks are not enough — you want to catch downtime before a visitor (or Googlebot) does. Repeated 5xx responses during crawls hurt search indexing, and downtime during an AdSense review is actively harmful. Use the Uptime Checker to batch-test your key URLs after every deployment, and see the website uptime monitoring guide for how status codes, redirects and TLS issues affect SEO. When an API endpoint (rather than a page) is misbehaving, test it directly with the online API client to see raw headers and response bodies.

Bottom line: one outside-in request answers “down or just me.” 5xx or timeout → their problem, wait it out. 200 → your problem, and the fix is almost always DNS, network or an overzealous extension.