5xx Status Codes Explained: When Your Server Is the Problem
A 5xx status code means your infrastructure failed, not the visitor's request. The server accepted the request, understood it, and then could not produce a valid response, so every 5xx on your site is an incident you own.
What separates 5xx from 4xx
RFC 9110 defines 5xx as "Server Error": the server is aware that it has erred or is incapable of performing the requested method. That is the whole distinction. A 404 says "there is nothing here". A 500 says "there is something here and I broke while producing it".
Two consequences follow. First, a 5xx is usually retryable, because the same request may well succeed a second later once the failing component recovers. Second, search engines treat a 5xx as a temporary signal and back off crawling rather than deindexing immediately, whereas a persistent 5xx over days does eventually cost you indexed pages.
Which hop failed
Read a 5xx code as a map of where the request died. Almost every modern site puts at least one proxy in front of the application, so the code tells you which side of that boundary failed.
| Code | Who produced it | What happened |
|---|---|---|
| 500 Internal Server Error | The application itself | Unhandled exception or unexpected condition inside the app |
| 501 Not Implemented | The server | The request method is not supported at all |
| 502 Bad Gateway | The proxy, CDN or load balancer | The backend answered, but with something invalid, or closed the connection |
| 503 Service Unavailable | The server or proxy, deliberately | Overloaded or in maintenance, and refusing work on purpose |
| 504 Gateway Timeout | The proxy, CDN or load balancer | The backend never answered in time |
| 505 HTTP Version Not Supported | The server | The protocol version in the request is not supported |
502, 503 and 504 carry the most diagnostic value, because each names a different failure of the same backend: invalid answer, refused answer, no answer. The 502 Bad Gateway guide covers the first of them in depth, including the proxy log lines that identify the exact fault.
Common causes behind 5xx responses
- Application crashes. An unhandled exception, a failed database connection or a null value in an unexpected place produces 500 on whichever routes touch the broken code path.
- Backend process not running. A stopped app server, a dead PHP-FPM pool or a container that failed its health check gives the proxy nothing to talk to, which surfaces as 502.
- Resource exhaustion. Out of memory, out of file descriptors, out of worker threads or out of database connections. Usually starts as intermittent errors under load before becoming constant.
- Slow dependencies. A slow query, a slow third-party API or a cold start pushes response time past the proxy's timeout and turns into 504.
- Deploys and restarts. Any window where the old process has stopped and the new one has not started serving yet produces a burst of 502 or 503.
- Configuration errors. A wrong upstream address, a bad TLS setup between proxy and backend, or a protocol mismatch such as speaking HTTP to an HTTPS port.
- Disk full. An underrated cause. Logs or temporary files fill the volume, sessions or caches stop writing, and the application starts failing in ways that look random.
How to work through a 5xx
- Confirm the code and its origin. Fetch headers directly and look at which component signed the response:
Acurl -sS -o /dev/null -D - https://example.com/Server:or CDN header on the error tells you whether the edge or the origin generated it. - Test the origin directly, bypassing the proxy. If the backend answers 200 on its own port while the public URL answers 502, the fault is in the proxy layer or the link between the two.
- Read the proxy error log next, not the application log. Reverse proxies name the failure precisely, for example
connect() failed (111: Connection refused)orupstream timed out, which immediately separates "backend down" from "backend slow". - Then read the application log. For a 500, the stack trace is the answer. For 502 and 504 the application often logs nothing at all, and that absence is itself informative.
- Check resources on the host. Memory, disk, connection counts and worker saturation. Intermittent 5xx under traffic is almost always a limit being reached.
- Look at what changed. Deploys, config pushes, certificate renewals and dependency updates account for a large share of sudden 5xx onsets.
Catching intermittent 5xx errors
5xx errors are often intermittent, which is what makes them hard to catch by hand: the page you reload works, and the one your customer loaded did not. A scheduled HTTP check runs continuously and samples the site far more often than you can, so a run of errors becomes visible as a pattern rather than as scattered complaints. Checking from many locations also separates a real server fault from a routing or edge problem that affects only part of the world, which is why distributed availability monitoring uses checkpoints spread across regions rather than a single vantage point. If the failing code turns out to be 403, 404 or 429 instead, the request never reached a broken backend, and the 4xx family guide is the right starting point.