500 Internal Server Error

HTTP 500 Internal Server Error is the generic response defined in RFC 9110 for any server-side fault that has no more specific 5xx status assigned to it. It tells the client that the request itself was almost certainly valid and reached the server, but processing failed for reasons outside the client's control. Because it is a catch-all, a 500 carries almost no diagnostic information for the caller beyond confirming the failure happened on the server. The real cause always lives in application code, server configuration, or infrastructure, and finding it requires looking at server-side logs rather than the response body.

The most common trigger is an unhandled exception in application code: a null reference, a failed type coercion, a database query that throws instead of returning rows, or an unhandled promise rejection in Node.js. Frameworks like Express, Django, Rails, and Spring catch these exceptions at a top level and convert them into a generic 500 response so the process does not crash outright. In production, a well-configured framework logs the full stack trace server-side while showing the client only a bare error page, which is why a working request that starts throwing 500s usually points at a recent code deploy or a data edge case the code never anticipated.

Misconfiguration is just as common as bad code. On Apache, a syntax error in .htaccess, an unsupported directive, or a missing module referenced by RewriteEngine rules will make Apache refuse the request with a 500 before it even reaches PHP. PHP itself raises 500s for fatal errors such as a missing extension, a memory_limit exhausted mid-script, or a version mismatch between code and the installed PHP binary. Similar misconfiguration failures show up with wrong file permissions, an expired or malformed environment variable, or a framework running in production mode without required secrets set, all of which fail before any application logic executes.

Diagnosing a 500 always starts with the server's error log rather than the browser. Apache and nginx write a distinct error log separate from the access log, PHP-FPM logs fatal errors with a file and line number, and application frameworks typically emit a stack trace with a timestamp and request ID that can be correlated across load balancer, web server, and app logs. Centralized logging or an APM tool such as Sentry, Datadog, or CloudWatch makes this correlation far faster than SSH-ing into a box. Reproducing the failing request locally with the same input, and turning on verbose or debug logging temporarily, usually narrows the cause within minutes.