HTTP Status Codes
With the distinctions that matter operationally — 502 against 503 against 504, and which of them your load balancer is generating rather than your application.
Runs in your browser
Web
Nothing matches that.
The 5xx codes people confuse
When something is broken in production, the distinction between these four is the first useful diagnostic — it tells you which component is unhappy before you read a single log line.
- 500 — your application ran and threw
- The request reached your code. The stack trace is in your application log, not the web server's.
- 502 — the proxy could not get a valid reply
- Generated by nginx or the load balancer, not by your app. The backend died mid-request, refused the connection, or spoke something the proxy could not parse. Check whether the process is running and whether the socket path or port matches.
- 503 — deliberately unavailable
-
Usually maintenance mode, a full queue, or no healthy backends. Unlike 502 this is normally
intentional, and it is the correct code to return while deploying. It should carry
Retry-After. - 504 — the backend never answered in time
- The proxy gave up waiting. The request may still be running server-side and may still complete — which is why a 504 on a payment endpoint is not proof the payment failed.