500 Internal Server Error

500 Internal Server Error is the server's catch-all confession: the request was fine, but something inside broke while handling it. An unhandled exception, a crashed process, a dependency that misbehaved — anything the code didn't anticipate ends up as a 500.

Common causes

• Unhandled exceptions — null references, type errors, panics; the request hit a code path nobody tested
• Database trouble — connection pool exhausted, migrations out of sync with the code, a query timing out and surfacing as an exception
• Bad deploys — missing environment variables, broken config, a dependency version mismatch that only explodes at runtime
• Downstream failures without handling — a third-party API call throws, and instead of degrading gracefully the whole request 500s
• Resource exhaustion — out of memory, out of file descriptors, disk full (logs and temp files are the usual culprits)
• Permission and filesystem errors — the app can't write where it expects to (see 403 for the web-server variant)

Intermittent vs constant

• Every request 500s → deploy or dependency-wide failure; roll back first, diagnose second.
• Some requests 500 → data-dependent bug (one user's record, one input shape) or one bad instance behind the load balancer.
• Bursts of 500s → resource exhaustion cycles, restart loops, or a downstream dependency flapping.

Debugging

The response body is deliberately generic (leaking stack traces is a security hole), so the truth lives in your logs and error tracker — correlate by timestamp and request ID. Reproduce with the free API tester to confirm which exact input triggers it.

Because 500s are precisely the thing you never want users to find first, this is the code most worth monitoring for: an HTTP monitor alerts on any 5xx by default, and multi-region confirmation separates "one flaky request" from "the service is broken". Pair it with response-time tracking — 500s are often preceded by minutes of degrading latency.