500 Internal Server Error

Of every error code on the web, 500 is the one that tells you least about the cause and most about the responsibility. It means: The server received your request, understood it, began to process it, and then hit a condition it did not know how to handle.

The HTTP specification describes it as the response for "an unexpected condition that prevented it from fulfilling the request". Unexpected is the operative word. A 500 is what a server sends when it has run out of more specific things to say.

What is actually happening

In the overwhelming majority of cases, an unhandled exception. Somewhere in the application code that was assembling your page, something threw an error that nobody caught - A null value where an object was expected, a division by zero, a malformed row in a database, a library that raised something the calling code did not anticipate.

The web server catches that at the outermost layer, logs a stack trace, and returns 500 because the alternative is returning a half-built page or nothing at all. On the server side there is almost always a detailed error in a log file with the exact line number. On your side there is a number.

Other, less common producers of a 500:

• Database connection exhaustion. The pool is full, a query cannot get a connection, and the resulting exception surfaces as a 500. Common under load.
• A misconfiguration. On Apache, a syntax error in .htaccess produces a 500 for every request under that directory. This is far and away the most common cause on shared hosting.
• Permissions. A script that cannot be executed, or a directory the server cannot read, on hosts that run scripts directly.
• A memory limit. The process was killed mid-request for exceeding its allocation.
• A failed deploy. Code shipped that references something not yet present - A migration not run, an environment variable not set.

Why this one is never your fault

The 5xx family exists to distinguish server errors from client errors. A 404 or a 403 is the server saying your request was wrong. A 500 is the server saying its own handling was wrong.

That distinction is worth holding onto, because the standard advice people are given - Clear your cache, restart your router, try a different browser - Makes no sense here. Your request arrived and was understood. The failure came afterwards, in code you have no access to.

500 versus its more specific relatives

The practical difference matters when you are estimating how long to wait. A 502 or 504 usually means an application process has died or stalled and will be restarted automatically within minutes. A 503 with a Retry-After header is a deliberate and usually brief decision. A 500 is a code bug, and a code bug needs a human to deploy a fix - Which takes longer.

What to do as a visitor

1. Reload once. If the error came from a transient condition - A connection that timed out, a race - A second request may well succeed. Once, not repeatedly.
2. Note exactly what you did. A 500 on one specific action is far more useful to report than "the site is broken". It tells the operator which code path to look at.
3. Try without the query string. If the URL has parameters, loading the bare page tells you whether the error is specific to that input.
4. Check whether it is everyone. A check from another network distinguishes a site-wide failure from something specific to your request or session.
5. Wait. Genuinely the answer. Consumer-facing 500s at large services are usually noticed within minutes because error-rate alerting is standard.

If it is your site

The log has the answer. On any modern stack the 500 was accompanied by a stack trace with a file and line number; the whole job is finding where that goes. Application logs first, then the web server error log, then the platform's log aggregator.

Three checks that resolve a large share of cases before you read anything: Did something deploy in the last hour, is the database reachable and under its connection limit, and is the disk full. The third causes remarkably many 500s and is invisible until you look, because a server that cannot write a session file or a temp file fails in ways that look nothing like a storage problem.

On shared hosting with Apache, check .htaccess first. A single unsupported directive produces a 500 for every request under that directory, and renaming the file to test takes five seconds.

Never show a stack trace to the public. A debug page exposes file paths, library versions, environment variables and sometimes credentials - That is a real disclosure, not a theoretical one. The generic page is generic for a reason.