When WebsiteDown checks a domain, one of the first things we report is the HTTP status code. That three-digit number carries more information than most people realize — it usually tells you which layer broke and, more usefully, whether there is anything you can do about it.
The three that cause the most confusion are 502, 503, and 504. They all appear when a site is broken, they all look alike in a browser, and they mean genuinely different things. We will cover the full map first, then spend real time on those three.
2xx — Success
A 200 OK response means the server received the request and returned a response without errors. This is the expected state for a healthy website.
204 No Content is sometimes returned by APIs — a valid response indicating the request succeeded but there is no content to return. For a browser-facing URL, this often indicates a misconfiguration.
A 2xx response from a monitoring check means the server is reachable and functioning at the network layer. It does not guarantee the application is working correctly — see content validation.
3xx — Redirects
301 and 302 responses are redirects. They are normal and expected — most sites redirect HTTP to HTTPS, or www to non-www. Monitoring tools should follow redirects and report the final status code.
A redirect loop (a site redirecting to itself infinitely) causes a browser to show an error after following some number of redirects. A monitor following redirects will eventually timeout or hit a redirect limit, reporting an error even though the server is technically responding.
4xx — Client errors
400 Bad Request means the server understood the request but rejected it, usually because it was malformed.
401 and 403 mean the resource requires authentication or the client is not authorized. Many monitoring tools get 403 responses when checking sites that block data center IP ranges — this is the site working correctly, not failing.
404 Not Found is often misread as a site being down. A 404 means the server is running and responding — it just did not find the specific resource requested. The server is up; the URL might be wrong.
429 Too Many Requests means the server is rate-limiting the client. For monitoring tools hitting the same URL repeatedly, this is increasingly common.
5xx — Server errors
This is the class that indicates actual server-side failure.
500 Internal Server Error is the generic catch-all for when something unexpected went wrong on the server. Deployment errors, unhandled exceptions, and database failures often produce 500s. A 500 usually means the application ran and threw.
502, 503, and 504 are the ones worth understanding properly — see the next section.
502 vs 503 vs 504: the three that get confused
Modern sites are rarely one machine. There is almost always something in front — a load balancer, a CDN, a reverse proxy like nginx — and an application server behind it. These three codes describe three different ways that relationship can fail, and the front layer is the one reporting the failure in all three cases.
502 Bad Gateway — the proxy reached the application and got a reply it could not use. The application answered, but with garbage, a malformed response, or it closed the connection mid-sentence. In practice this most often means the application process crashed or restarted while serving, or a deploy is in progress and the new process is not accepting connections cleanly.
503 Service Unavailable — the server understood the request and is deliberately refusing to serve it right now. This is the honest "we are not available" response. It is what a well-configured system returns when the app is intentionally stopped for maintenance, when a health check has pulled every backend out of the pool, or when a rate limiter or overload protector sheds traffic on purpose. Of the three, 503 is the one most likely to have been chosen deliberately rather than stumbled into. We have a dedicated deep-dive on this one at /blog/what-is-503-error.
504 Gateway Timeout — the proxy reached the application and then waited, and the application never answered in time. Nothing crashed and nothing refused you; something is just too slow. The classic cause is a database query that has stopped returning, an upstream API call with no timeout, or a thread pool that is fully saturated so your request never gets picked up.
The mental model that makes these stick: 502 is a broken answer, 503 is a refused answer, 504 is no answer in time.
What each one implies about how long it will last
The three codes carry different expectations, which is useful when you are deciding whether to wait or walk away.
502 tends to be the shortest-lived. If it is a deploy rolling through or a process that crashed and is being restarted by a supervisor, it often clears within seconds to a few minutes. A 502 that persists for a long time means the application is failing to start at all, which is a more serious problem.
503 depends entirely on intent. A planned maintenance 503 lasts as long as the maintenance window, and a good one includes a Retry-After header telling clients when to come back. A 503 caused by overload clears when the traffic spike passes or capacity is added — which can be minutes or hours.
504 is often the worst sign of the three for a visitor, because it usually means the system is still up and trying but is saturated or stuck. Timeouts under load also tend to cascade: slow requests pile up, consume resources, and make everything else slower.
None of these are things a visitor can fix. Which brings us to the actually useful question.
What you can (and cannot) do about each
If you are a visitor, the honest answer is: very little, and that is worth knowing so you do not waste an hour.
Clearing your cache will not fix a 502, 503, or 504. Neither will a different browser, flushing DNS, or restarting your router. All three of these codes were generated by the site's own infrastructure and delivered to you successfully — the network between you and the site is working fine. The only visitor-side action with any value is waiting and retrying, ideally not in a tight loop, since retry storms make overload worse for everyone.
The genuinely useful move is to confirm it is not just you and then stop refreshing: run a check from outside your network, and if the site is broadly down, set an alert so you get told when it recovers instead of manually reloading.
If it is your site, the code tells you where to look first. A 502 points at the application process — check whether it is running, whether a deploy is stuck, and read the proxy's error log, which will usually name the upstream that failed. A 503 points at intent and capacity — check whether maintenance mode is on, whether health checks have drained the backend pool, and whether a rate limiter is shedding load. A 504 points at slowness rather than failure — look for long-running queries, an upstream dependency that has stopped responding, and whether your proxy timeout is simply shorter than a legitimately slow endpoint.
In all three cases, the proxy layer's logs are more informative than the application's, because the proxy is the component that made the decision to return the error.
Timeouts — no status code at all
A timeout is different from any of the above: the server never responded at all within the allowed window. This typically means the server is completely unreachable — the network path is broken, the process has crashed, or the machine is gone.
Note the distinction from a 504. A 504 is a status code, which means something at the site answered you; a proxy was alive enough to report that its backend was too slow. A raw connection timeout means nothing answered at all.
That makes timeouts the more severe signal. A 503 means the server is struggling but present. A timeout means there is no one at the other end of the request.
The 200 that is lying to you
The final case is the one status codes cannot describe. A site can return a perfectly healthy 200 OK while being completely broken for humans — the CDN stays up and serves a cached shell, or the page loads and the JavaScript that renders the actual content fails.
This is why status-code-only monitoring misses a real class of outages. A check that only asks "was the code under 400" will call that page healthy.
Our checks compare the size of the response body against what the site normally returns. A page that usually sends tens of kilobytes of HTML and suddenly sends a few hundred bytes gets flagged as content drift even though the status code is a clean 200. It is a cheap way to catch the failure mode where everything is technically fine except the part the user came for.
Checking a status code yourself
If you want the raw code for a URL rather than a browser's interpretation of it, our HTTP status checker at /tools/http-status-checker sends a live request and shows exactly what came back, including the redirect chain if there is one.
That last detail matters more than it sounds. Browsers follow redirects silently, so the code you care about is often the one at the end of a chain of three hops, and the failure is sometimes a redirect loop rather than the destination being down at all.