Is Site Down or Just Me? A Fast, Accurate Way to Find Out

Downdetector classifies services as having no problems, possible problems, or problems based on user reports and other signals—not simply on whether one browser request fails. That distinction matters when you search is site down or just me: within a few minutes, you can separate a real outage from a browser, DNS, VPN, ISP, or regional delivery problem and choose the right next step. (downdetector.com)

Start with two independent checks

The fastest reliable answer is not to refresh the same tab repeatedly. Run the URL through an external website down checker, then try it from a second network—usually mobile data with Wi-Fi turned off.

Tools such as Down For Everyone Or Just Me and the IsItWP Website Uptime Checker test availability away from your device. That makes them useful evidence, though one external probe is still only one observation from one location. (downforeveryoneorjustme.com)

Use this 60-second sequence:

1. Enter the exact URL in an external checker, including the relevant subdomain such as www, app, or status.
2. Open the same URL on your phone using cellular data, not the same Wi-Fi connection.
3. Try a private/incognito window or another browser.
4. Check whether other unrelated sites load normally on your original connection.
5. Record the exact browser message or HTTP status code rather than describing it only as “down.”

If the external checker and mobile data both fail, a wider outage is likely. If they work while your home or office network fails, do not assume the site is offline: the evidence points to a local network, DNS resolver, VPN, extension, firewall, or location-specific issue.

Is site down or just me? Read the evidence correctly

A website can be available to some visitors and unavailable to others. Modern sites commonly use CDNs, load balancers, web application firewalls, geolocation rules, and multiple DNS providers. A successful check in one city does not prove that every visitor can reach the site.

A practical interpretation grid

Downdetector is especially useful for major consumer platforms because it aggregates user reports and displays a 24-hour report pattern and outage map. Treat it as corroboration rather than a technical diagnosis: a report surge can show that many people are affected, but cannot identify whether the failure is DNS, authentication, the origin server, or a CDN. (downdetector.com)

Use a website down checker, then compare locations

A basic site outage checker answers one narrow question: could its server retrieve a response from the URL right now? That is valuable, but it does not confirm how the page behaves for every country, ISP, logged-in user, or device.

For a public service such as YouTube, Slack, or an online bank, start with Downdetector and the service’s official status page. For an ordinary domain, use a URL-based checker such as IsItWP or Down For Everyone Or Just Me, then repeat from your phone and, when the stakes are high, a regional testing service.

Why regional comparison changes the diagnosis

Consider a store hosted behind a CDN. Visitors in Chicago receive 200 OK, while visitors in one overseas region receive a timeout. Calling the entire site “down” hides the useful fact: the origin may be healthy, but a regional edge, DNS answer, route, or access rule is failing.

Write down these four details from every test:

• Location or network: home fiber, office Wi-Fi, cellular, or external probe region.
• Exact URL: https://example.com/ may work while /checkout fails.
• Time: preferably with timezone, such as 14:20 UTC.
• Response: timeout, DNS error, 403, 404, 429, 502, 503, or 504.

This small incident record is more useful to a host or developer than “the website is broken.” It also lets you identify intermittent incidents that disappear before support can reproduce them.

Check the browser without mistaking it for a global test

Your browser is part of the delivery chain. Cached redirects, stale cookies, service workers, ad blockers, privacy tools, corporate endpoint protection, and VPNs can all alter the result you see.

First, open a private or incognito window. This reduces the influence of stored cookies and extensions, although it does not eliminate every network-level cause. Next, try a second browser. If Firefox loads the site and Chrome does not, that is strong evidence against a total site outage.

Then disable a VPN or proxy temporarily and retry. A site might block a VPN exit IP, apply country restrictions, or trigger an automated-traffic rule. Conversely, a VPN can be a useful diagnostic: if the site fails from your local IP but works through another country, the issue is likely regional or policy-based rather than a universal outage.

Do not clear all browser data as your first reaction. You may lose active sessions and useful evidence. Capture a screenshot of the error, note the address bar URL, and try incognito mode before changing anything.

For site owners, browser-only failures may look like a traffic drop or support complaint even when the server is healthy. If you recently changed crawler rules, distinguish visitor access from search crawling; our guide to a site disappearing after blocking Googlebot explains why those are related but separate recovery problems.

Test a second network to rule out your ISP or router

Switching networks is one of the highest-value checks because it changes multiple variables at once: your public IP address, ISP route, DNS resolver, Wi-Fi equipment, and often your geographic network path.

Use mobile data deliberately:

1. Turn off Wi-Fi on your phone.
2. Open the exact page, not a search-result preview.
3. If it loads, return to the affected network and test again.
4. If it fails on both networks, use an external checker or ask a colleague in another region to test.

If your office network is the only failing environment, an organization’s firewall, secure web gateway, or DNS filtering policy may be involved. If only your home network fails, rebooting the router can renew a connection and discard temporary local state, but it will not repair a genuine host outage.

A ping test can offer another clue, but it is not an uptime test. Many healthy servers and CDNs ignore ICMP ping traffic by design. A failed ping does not prove a website is offline; an HTTP request that returns a status code tells you much more about whether the web service responded.

Check DNS before blaming the web server

DNS translates a human-readable domain name into an IP address or other routing target. ICANN describes DNS as the system that lets people use domain names instead of memorizing IP addresses. If DNS fails, your browser may never reach the website server at all. (icann.org)

Typical browser DNS messages include DNS_PROBE_FINISHED_NXDOMAIN, “server not found,” or “cannot find the server.” These can mean the domain genuinely has no usable record, but they can also result from a local resolver issue, stale cache, network interception, or a recent DNS change that has not reached every resolver.

A simple DNS comparison

On Windows, use:

nslookup example.com

On macOS or Linux, use:

dig example.com

Run the lookup using your normal network, then compare it from cellular or an external DNS lookup service. If one resolver returns an address and another returns NXDOMAIN or times out, the site may be suffering a DNS propagation, delegation, authoritative nameserver, or resolver-specific problem—not necessarily a complete origin outage.

Google’s Public DNS troubleshooting guidance specifically covers slow resolution, incorrect answers, blocked or hijacked queries, and no responses. Domain operators may also need to investigate authoritative nameservers, delegation, and DNSSEC when a failure is global. (developers.google.com)

For a visitor, changing DNS resolvers can be a short-term test, not a cure-all. For an owner, DNS monitoring from multiple resolvers is a sensible part of uptime monitoring.

Decode HTTP errors: timeout, 403, 404, 429, and 5xx

An HTTP status is not merely an error label; it identifies which layer answered your request. IANA groups 4xx codes as client errors and 5xx codes as server errors, while 2xx indicates success and 3xx indicates a redirect. (iana.org)

A HTTP 502 Bad Gateway error means a server acting as a gateway or proxy received an invalid upstream response. When Cloudflare is involved, a Cloudflare-branded 502 or 504 commonly means the origin responded with that error; an unbranded 502/504 can instead originate at Cloudflare. Either way, one 502 does not prove permanent shutdown, and it may affect only some paths or regions. (developers.cloudflare.com)

Tell a temporary outage from a permanently shut-down site

A dead-looking website is often temporarily broken. Maintenance, expired certificates, host incidents, database failures, DNS mistakes, unpaid infrastructure, or a failed deployment can all produce errors that resemble abandonment.

Avoid declaring a site permanently shut down after a single 502, timeout, or DNS message. Instead, check over time and from different networks. A genuine permanent closure is more plausible when the domain returns 410 Gone, the organization has announced closure, its official social or status channels confirm it, and the condition persists across multiple locations.

A 404 Not Found means one resource was not found; it does not mean the domain is gone. A 410 Gone is a stronger signal that a specific resource was intentionally removed, but even that does not prove the entire business or website has ceased operating. RFC 9110 and IANA list both codes separately for precisely this reason. (rfc-editor.org)

If you need content while a site is unavailable, try an official alternate domain, a published status page, a mobile app, a cached search result where legitimately available, or a reputable archive for historical material. Do not enter credentials through lookalike “mirror” sites or bypass access controls.

What site owners should do during and after an outage

For owners, the goal is not just to see that a homepage has recovered. Confirm that critical user journeys work: homepage, login, forms, checkout, APIs, and XML sitemap endpoints. Test from more than one region when you use a CDN or serve an international audience.

A concise recovery sequence looks like this:

1. Confirm DNS resolves consistently through more than one resolver.
2. Check 200 responses and server response time for critical URLs from multiple networks.
3. Review host, application, CDN, and deployment logs around the first failure time.
4. Verify redirects, canonical URLs, robots directives, and sitemap availability after rollback or migration work.
5. Keep uptime monitoring in place so the next incident has a start time, duration, and evidence trail.

Uptime monitoring should make a request at intervals from independent locations and alert you when it fails repeatedly. It cannot guarantee every visitor’s experience, but it is far better than learning about downtime only through customers.

Once the site is stable, search discovery is a separate job. Indexa does not determine whether a website is down; it monitors XML sitemaps locally and can submit new or updated URLs through supported official indexing APIs after recovery. That can be useful when recovered pages, redirects, or migration fixes need to be discovered again. For a broader checklist, see our guide on pages not indexed after a site migration and our practical guide to automatically submitting new pages to Google.

FAQ

How can I tell whether a website is down for everyone or only me?

Check the exact URL with an external website down checker, then open it on mobile data with Wi-Fi disabled. If both independent tests fail, a wider issue is likely. If they work while your normal connection fails, investigate your browser, VPN, router, ISP, firewall, or DNS resolver rather than assuming the site is offline.

What does a 502 Bad Gateway error mean, and does it prove the site is offline?

A 502 means a gateway or proxy received an invalid response from an upstream server. It often indicates an origin, reverse proxy, CDN, or application problem, but it does not prove the entire site is permanently offline. Test another page, network, and region; Cloudflare also distinguishes between origin-generated and Cloudflare-generated 502/504 responses. (developers.cloudflare.com)

How can I check a website’s status from another location or network?

Use cellular data instead of your usual Wi-Fi, ask a colleague in another city to test, or use a regional uptime checker that reports where it made the request. Compare the exact URL, response code, and time. A homepage result from one location cannot rule out regional routing, CDN, or geoblocking problems.

How do I access a website when it is down?

First verify that it is truly unavailable rather than blocked only on your network. You may be able to use an official mobile app, the organization’s status page, a legitimate alternate network, or an archived or cached public version for historical information. Do not use unofficial login mirrors or attempt to bypass authentication, paywalls, or access controls.

What causes a website to be unavailable even when other sites work?

One site can fail while the rest of the internet works because its DNS records, hosting origin, CDN route, certificate, web application firewall, account, specific API, or deployment is failing. It can also be a local issue: a stale DNS cache, VPN IP block, browser extension, corporate filter, or ISP routing problem can affect one domain only.