5xx Server Error HTTP Status Codes
5xx responses indicate that the server failed to fulfill a valid request. The problem is on the server side, not the client’s. Most 5xx errors are retryable and should trigger alerting in production systems.
All 5xx Codes
| Code | Name | Summary | Guide |
|---|---|---|---|
| 500 | Internal Server Error | Generic server-side error. Something went wrong that is not covered by a more specific code. | Guide |
| 501 | Not Implemented | Server does not support the HTTP method used in the request. | Guide |
| 502 | Bad Gateway | Upstream server returned an invalid response to the proxy or gateway. | Guide |
| 503 | Service Unavailable | Server temporarily unable to handle requests. Overload or maintenance. | Guide |
| 504 | Gateway Timeout | Proxy or gateway did not receive a timely response from the upstream server. | Guide |
| 505 | HTTP Version Not Supported | Server does not support the HTTP version in the request. | Guide |
| 506 | Variant Also Negotiates | Server configuration error in content negotiation. | Guide |
| 507 | Insufficient Storage | WebDAV: server cannot store the representation needed to complete the request. | Guide |
| 508 | Loop Detected | WebDAV: server detected an infinite loop while processing a request. | Guide |
| 509 | Bandwidth Limit Exceeded | Non-standard: monthly bandwidth cap exceeded (common in shared hosting). | Guide |
| 510 | Not Extended | Experimental: server requires an HTTP extension that was not sent. | Guide |
| 511 | Network Authentication Required | Client must authenticate with the network (captive portal) before access is granted. | Guide |
The Most Common 5xx Errors and What Causes Them
500 Internal Server Error: The Catch-All
500 is the fallback for any server-side error that is not covered by a more specific code. Unhandled exceptions, database query failures, null pointer dereferences, and misconfigured server environments all typically produce 500. In production, a spike in 500 errors almost always indicates a code deployment issue, a database problem, or a resource exhaustion event (memory, disk, file descriptors). Check application logs immediately.
In development, 500 usually comes with a stack trace that pinpoints the problem. In production, the stack trace should be logged internally but never sent to the client — it exposes internal system details to potential attackers.
502 Bad Gateway: Upstream Failure
502 Bad Gateway means a proxy or load balancer received an invalid response from an upstream server. If your architecture is: browser → CDN → load balancer → application server, a 502 at the CDN means the load balancer or application server is down or returning garbage. A 502 at the load balancer means the application server is unreachable or crashed.
Common causes: application server crashed and is not accepting connections; application server returned a response the proxy could not parse; upstream timeout that resulted in a truncated response; deployment in progress with zero application server instances running.
503 Service Unavailable: Planned and Unplanned Downtime
503 Service Unavailable means the server cannot handle requests right now. For planned maintenance, return 503 with a Retry-After header indicating when the service will be back. For overload situations, return 503 with Retry-After to tell clients when to retry rather than hammering a struggling server.
503 is the correct response for rate limiting at the server level (as opposed to 429 which is per-client rate limiting). Circuit breakers in microservice architectures return 503 when a downstream dependency is unhealthy and further requests would be wasted.
504 Gateway Timeout: Slow Upstream
504 Gateway Timeout is the proxy’s report that the upstream server took too long to respond. This is distinct from 408 Request Timeout (the server waited for the client to finish sending the request). 504 is typically caused by: slow database queries, downstream API calls that are timing out, background processing on the application server that is delaying response time, or resource starvation (CPU, memory) causing slow processing.
5xx vs 4xx: Whose Problem Is It?
The key question when debugging an error response: is the problem in the request (4xx) or in the server (5xx)?
5xx errors are the server’s fault. The client sent a valid request; the server failed to handle it. Retrying the same request may work (especially for 502, 503, and 504, which are often transient). Monitoring alerts should fire on 5xx spikes because they indicate infrastructure problems that need human intervention.
4xx errors are generally the client’s fault. The request was malformed, unauthorized, or targeting a non-existent resource. Retrying will usually produce the same error. 4xx errors should not trigger server alerts (except for 429, which can indicate an attack pattern).