HTTP 5xx Server Error Codes

HTTP 5xx server error status codes

The 5xx class is the server admitting fault: the request may have been perfectly valid, but something on the server side — the app, a gateway, an upstream dependency, or capacity — failed. Because the client did nothing wrong, many 5xx errors are transient and worth retrying. Knowing which ones to retry, how to back off, and when to page someone is the difference between a brief blip and a cascading outage. Search the reference above by code or keyword for retry and alerting guidance on each.

How it works

A 5xx response is generated when the server cannot fulfil an apparently valid request. 500 Internal Server Error is the generic catch-all for an unhandled exception. The gateway family — 502 Bad Gateway and 504 Gateway Timeout — appears when a reverse proxy or load balancer cannot get a good or timely response from an upstream. 503 Service Unavailable signals overload or maintenance and should carry a Retry-After header. For retries, combine exponential backoff with jitter to avoid synchronized retry storms, and cap the number of attempts. For observability, alert on the 5xx rate (and error budget burn) rather than raw counts, since a few errors are normal at scale.

Tips and examples

• Implement retries with backoff and jitter for 502/503/504, but make sure the operation is idempotent first so a retry cannot double-charge or double-create.
• Always emit Retry-After on 503 during maintenance — it keeps clients calm and tells search crawlers the outage is temporary.
• Separate your dashboards: a 502/504 spike points at upstream/dependency health, while a 500 spike usually points at your own recent deploy.
• Return a minimal, non-leaky body on 5xx. Never expose stack traces or internal hostnames to untrusted clients.