Responses
Server errors
Recognize internal failures, bad gateways, unavailable services, and gateway timeouts while keeping useful diagnostics out of public responses.
A 5xx status means the server failed to complete a request it should have handled. The client looked valid; something broke on the server side or on the path to it.
Common codes:
500 Internal Server Error: unexpected application exception.502 Bad Gateway: a proxy received garbage or no response from upstream.503 Service Unavailable: overload, maintenance, or deliberate drain.504 Gateway Timeout: upstream did not answer in time.
Visitors should see a calm, generic page. “Something went wrong” is enough. Detailed stack traces belong in logs, linked to the request by an ID such as x-request-id when you control the headers.
When I debug 5xx errors, I work in this order: exact status code, response body (often HTML from the CDN), application logs for the same timestamp, then any gateway or load balancer in front of the app. A 502 frequently originates in nginx or Cloudflare, not in your Node process.
Simulate a server error:
curl -i https://httpbin.org/status/500The status line reads HTTP/1.1 500 INTERNAL SERVER ERROR. httpbin keeps the body minimal on purpose.
Distinguish gateway failures:
curl -i https://httpbin.org/status/502
curl -i https://httpbin.org/status/504Both are 5xx, but your runbook differs. 502 suggests fix the upstream or the proxy config. 504 suggests timeout budgets, slow queries, or a stuck dependency.
Do not return 5xx for validation mistakes that belong in 4xx. Calling a bad input a server error trains clients to retry forever and pollutes your error budgets.
Try this on your own project: confirm your production error page hides internals, then find one recent 5xx in logs and trace whether it was application code, a gateway, or an external API timeout.
Quick check
Result
You got of right.
Lesson completed