# HTTP Error Codes Explained: 500, 502, 503, 504 and What They Mean for Your Clients > An error reference for the key HTTP 5xx codes: cause, fix, and how monitoring reports the error before your client calls. Source: https://uptimeify.io/blog/http-error-codes-explained A white screen reading "500 Internal Server Error" or "502 Bad Gateway" means "broken" to most people, without them knowing what the code means. For you as an agency, though, that three-digit code is valuable diagnostic information: it reveals *at which layer* the problem sits and where to start looking. **The 5xx error codes aren't random gibberish. They're a precise signaling system.** This article explains the four most important ones, 500, 502, 503, and 504, what each means for your client, how you fix it, and how monitoring warns you before the first client call comes. - **5xx codes = server-side problem** (as opposed to 4xx, which concerns the client request, like a 404). - **500 Internal Server Error:** the application itself is broken: code bug, database issue, misconfiguration. - **502 Bad Gateway:** an upstream server got an invalid response from the backend. - **503 Service Unavailable:** the server is healthy but temporarily unavailable: overload or maintenance. - **504 Gateway Timeout:** the backend didn't respond in time: too slow or hanging. - **Monitoring reports every 5xx**, confirmed from multiple locations, before the client sees the error page. ## First, quickly: what the 5xx class even means HTTP status codes are organized into classes, and the first digit reveals the category. The 2xx codes mean success (200 OK), the 3xx redirects, the 4xx errors on the client's side, and the famous 404 ("not found") belongs here, because the browser requests something that doesn't exist. The **5xx class**, by contrast, signals: the request was fine, but the *server* couldn't fulfill it. The problem is on the operator's side, not the visitor's. That distinction is the first diagnostic step. A 5xx error means the visitor did nothing wrong and can do nothing: the fix is with you. And the second and third digits narrow the problem further: they say *which* layer of the server infrastructure is stuck. That's exactly the practical value we'll now break down code by code. One important note up front: unlike a DNS problem, where the site isn't found in the first place, with a 5xx error the path to the server is intact: the server does respond, just with an error. That's a different type of problem and needs a different search. The first digit of a status code reveals the category: 5xx means "the server couldn't fulfill the valid request." The problem is with the operator, not the visitor, and the further digits say at which layer. ## 500 Internal Server Error: the application is broken The 500 is the most generic 5xx error and also the most common. It's the way a server says: "I got your request, but something went wrong while processing it that I can't name more precisely." The code itself is deliberately unspecific: the actual cause is always elsewhere, namely in the server or application log. **What happens for the client:** the site starts to load, the domain is found, the server responds, but instead of content, an error appears. To the visitor it looks like "the site is broken," even though the surrounding infrastructure is running. For a shop, that often means: the cart or checkout breaks while the homepage still looks normal. **Typical causes:** a coding bug in the application, a failed or misconfigured database connection, an expired certificate for an internal service, a faulty `.htaccess` or server configuration, or an unhandled exception in the code, say after a deployment. **Where you start fixing:** always in the log. The application and server logs contain the concrete error message that the 500 withholds. A 500 is often tied to the most recent change: a deployment, a plugin update, a changed configuration. The question "what was touched last?" often leads to the cause faster than anything else. A 500 means "the application is broken, details in the log." The site responds, but the content fails. The fastest lead is almost always the most recent change: deployment, update, config. ## 502 Bad Gateway: wrong answer from the backend The 502 takes us into the world of layered infrastructure. Modern websites rarely run on a single server; often a gateway, a reverse proxy, a load balancer, a CDN, sits in front of the actual application server and forwards requests to it. A 502 Bad Gateway arises when this gateway forwards a request but gets an **invalid or unusable response** back from the backend. **What happens for the client:** similar to a 500, the visitor sees an error page instead of content. The difference is the source: it isn't the application itself reporting the error, but the upstream server reporting that it can't make sense of the backend's response. **Typical causes:** the application server (say a PHP-FPM, Node, or Python process) has crashed or was restarted and isn't responding cleanly right now. A misconfigured proxy forward points to a port where nothing (any longer) listens. Or the backend delivers a corrupt response the gateway can't interpret as valid HTTP. **Where you start fixing:** with the backend service behind the gateway. Is the application process running at all? A glance at whether the service is active and listening on the expected port clears up the most common cause. Then comes the proxy configuration: does the gateway point to the right address and port? A 502 means "the gateway got an invalid response from the backend." The search starts with the application process behind it: is it running, and is it listening on the right port the proxy points to? ## 503 Service Unavailable: healthy, but temporarily away The 503 is the friendliest of the four, because it often signals no real failure, but a deliberate state. "Service Unavailable" means: the server is fundamentally healthy but can't handle the request right now. Usually that's temporary and sometimes even intentional. **What happens for the client:** the site is briefly unavailable. A well-designed 503 shows an explanatory maintenance page ("We'll be right back") instead of a bare error message, and can include a `Retry-After` hint in the background telling search engines and browsers when to try again. **Typical causes:** ongoing maintenance or a deployment where the operator deliberately takes the service offline briefly. Or overload: too many concurrent requests, say after a viral post or an attack, so the server rejects new requests instead of collapsing. A service that's just restarting and isn't ready yet also often returns a 503. **Where you start fixing:** first clarify whether the 503 is intentional. If planned maintenance is running, all is well: the code is doing exactly the right thing. If it's unintentional, it usually points to capacity: are resources sufficient? Is there a load spike? For recurring 503s under load, scaling is the topic, not debugging. A practical point for agencies: because a 503 can occur both intentionally (maintenance) and unintentionally (overload), it's important to log planned maintenance as such in your monitoring, otherwise your own maintenance triggers a false alarm. A 503 means "healthy but not available right now": often maintenance or overload. First question: intentional or not? Planned maintenance belongs logged in your monitoring so it triggers no false alarm. ## 504 Gateway Timeout: no answer in time The 504 is the twin of the 502: the same layered gateway-and-backend setup, but a different failure mode. With a 502 a *wrong* answer came back; with a 504 Gateway Timeout **no answer came back in time at all**. The gateway forwarded the request to the backend and then waited, until a time limit was reached and it gave up. **What happens for the client:** the site loads for a long time and then shows an error page. The long wait beforehand is characteristic: unlike the 502, which often comes quickly, the 504 is the result of exhausted patience. **Typical causes:** a backend that's simply too slow: a database query that gets lost in a huge table, an external service (a payment API, a third party) the server waits on that is itself hanging, or an overloaded application server that can't work through requests fast enough. The common denominator is always time: something takes longer than the gateway is willing to wait. **Where you start fixing:** with the backend's performance. Which operation takes too long? Slow database queries are the most common suspect, followed by external calls without a sensible timeout. Sometimes the fix is an optimization (an index, a cache), sometimes a more realistic timeout in the gateway configuration, but the cause almost always lies in something that takes too long. A 504 means "the backend didn't respond in time." The suspect is always something slow: a hanging database query or an external call without a timeout. The search heads toward performance, not a crash. ## How monitoring reports the error before the client calls All this knowledge about error codes has one decisive catch: it only helps if you know the error is occurring at all. And here lies the real problem in agency life: a 500 or 502 on a client's site doesn't produce a call to *you* unless the client notices it themselves. Until then, the site may serve error pages to visitors for hours without anyone stepping in. That's exactly the gap website monitoring closes. The principle is simple: a monitor calls the site at short intervals, the way a visitor would, and evaluates the returned HTTP status code. If a 200 comes back, all is well. If a 5xx comes back, whether 500, 502, 503, or 504, the monitor detects the error and treats it as an outage. The silent error that only random visitors see becomes an active signal that reaches you. Two details turn this principle into a reliable tool. First, **confirmation from multiple locations**: before an alert fires, Uptimeify checks the error from multiple EU locations. A single, brief blip, a server that restarts in one second, thus triggers no false alarm; only a repeatedly confirmed 5xx becomes an incident. Second, **documentation with a timestamp**: the detected status code is recorded in the incident history: when the error began, which code came back, how long it lasted. That's both your diagnostic basis (which of the four codes was it?) and your proof toward the client (we detected it at 2:03 p.m. and fixed it at 2:15 p.m.). That closes the loop between knowing and acting: the error code tells you *what* is going on and where to look, and the monitoring tells you *that* something is going on, and before your client does. For a 5xx not to surface only through a client call, someone has to keep an eye on your client sites' status codes. Try monitoring that confirms every server error and documents it with a timestamp. ## From cryptic code to composed response The real value of understanding these four codes lies in the composure they give you. When the client calls, or better: when your monitoring pings you, the difference between panic and control is knowing what the code means. "502" is no longer a cryptic message but a clear direction: look at the backend process behind the gateway. "504" sends you to performance, "500" to the application log, "503" to the question of maintenance or load. Each code is a shortcut to the right place. For an agency, that's a double win. Internally, you save diagnostic time, because the code narrows the search instead of starting from zero. Externally, you look composed, because you don't tell the client "something's broken" but "that's a gateway timeout, the backend takes too long, we're on the cause." That precision is exactly the professionalism a client pays an agency for. And the basis of it all is knowing the error early. An error code no one sees helps no one: only the monitoring that confirms and reports it turns the knowledge from this article into a fast, calm response. Have both, the understanding of the codes and monitoring that reports them, and you turn the dreaded white error screen into a manageable routine. Turn the error code into a fast response. See how Uptimeify monitors your client sites' status codes, confirms every 5xx, and alerts you, before your client sees the error page.