Webmaster & Network·4 min read

Is It Down for Everyone or Just Me? A Practical Answer

The site won't load, the chat channel is filling up, and someone has to answer the only question that matters right now: is it down for everyone or just me? A single uptime probe from a neutral server settles it in seconds. If the check comes back UP while your browser shows an error, the problem lives somewhere between your machine and the site. If it comes back DOWN, the outage is real, and the status code usually tells you which layer failed. This article walks through both readings with concrete examples.

Open the tool All insights

Is it down for everyone or just me: the first uptime question

Local problems impersonate outages constantly.

A large share of reported outages aren't outages at all. Stale DNS in your OS cache, a VPN with a dead exit node, a corporate proxy, a captive portal at a cafe, or one misbehaving browser extension can each produce an error page that looks exactly like a dead server. Meanwhile the site is serving everyone else without a hiccup.

The fastest way to separate the two cases is a probe from a machine that isn't yours. The Uptime Check tool sends one HTTP request from our server and reports UP or DOWN, the status code, and the response time in milliseconds. One data point from outside your network is worth twenty refreshes inside it.

What a one-shot uptime probe does and doesn't test

It's a spot check, not a monitor.

The check requests your URL once, at the moment you click. It proves whether the server answered from our vantage point at that second. It doesn't watch the site overnight, retry on failure, or send alerts, and it can't detect regional failures where a CDN edge in one country breaks while the rest keep serving.

That's still plenty for the common cases: confirming a deploy came up, checking a client's site before a call, or verifying that the fix you just pushed restored service. Click Check now a few times over a minute and the 10-entry history becomes a small, timestamped picture of how stable things really are.

Reading downtime results: three worked examples

The same DOWN badge can mean very different things.

Say you probe https://example.com and get UP, status 200, 184ms. That's a clean bill of health: the server accepted the connection, returned the page, and did it quickly. Now suppose a check on your own domain returns DOWN with no status code at all. No code means no HTTP response ever arrived, which points at DNS, the network path, or a machine that's fully off.

A third pattern sits between those. Input: yoursite.com right after a bad deploy gives status 502 in 90ms. The connection worked and something answered fast, but the thing that answered was a proxy reporting that the application behind it is unreachable. Reading downtime results is mostly about recognizing which of these three shapes you're looking at.

Status codes during outages, from 500 to no code at all

The code names the layer that failed.

Status codes during outages are diagnostic gold because each one blames a different part of the stack. Learn five patterns and you can triage most incidents from a single probe:

500: the application itself threw an error. Start with your app logs, not your infrastructure.
502 or 504: a proxy or load balancer couldn't reach the backend or timed out waiting. The web tier is alive; the app tier isn't.
503: the server is up but refusing work, typical of overload, maintenance mode, or rate limiting.
521 or 522 from a CDN: the edge network is fine but it can't reach your origin server.
No code at all: nothing answered. Think DNS failure, firewall rule, or a stopped machine.

Uptime check mistakes that muddy the diagnosis

Bad probes produce confident wrong answers.

A probe is only as useful as the URL and the patience behind it. These habits cause the most confusion during an incident:

Probing only the homepage. The root URL is often cached by a CDN while every dynamic route behind it is dead. Test a page that actually exercises your application.
Trusting a single result. Transient blips happen; two or three checks spaced a minute apart tell you whether the failure is real and sustained.
Reading response time as page speed. The probe times one HTTP response, not images, scripts, fonts, or rendering.
Testing http:// when the site forces https. The extra redirect can distort timing and occasionally mask the real failure.

Getting sharper answers from a quick uptime check

First, probe something deep. If your stack exposes a health endpoint like /api/health, check that alongside the homepage; the pair distinguishes a CDN serving stale cache from an application that's genuinely alive. Second, use the history as a rhythm during recovery: probe every 30 seconds after a restart and you'll see the exact moment 503s turn into 200s, with timestamps you can paste into the incident channel.

Third, check both the bare domain and the www variant. Misconfigured redirects between the two are a classic way for a site to be half down, working for some bookmarks and broken for others.

Where Uptime Check ends and other network tools begin

When a probe returns DOWN with no status code, drop to DNS: the DNS Lookup tool shows whether the domain resolves at all, and Domain to IP confirms which address it points to. When the result is UP but the content looks wrong, the HTTP Headers Checker reveals cache headers and server signatures that explain what's actually serving.

If a code appears that you don't recognize, the HTTP Status Codes reference defines every one. And when you suspect your own connection is the problem, What Is My IP is a quick way to confirm which network and address you're actually testing from.