HTTP 500 Internal Server Error

Quick reference

What it means

The server received the request, understood it, and then failed internally while processing it. The HTTP layer itself is functional — traffic is flowing and the server is listening. The failure is in the application layer: code that threw an exception, a database query that failed, a config value that was missing, or a dependency that did not respond.

500 is the default fallback for any server-side error that does not fit a more specific 5xx code. If a more precise code applies — 502 for upstream proxy failure, 503 for deliberate unavailability, 507 for storage exhaustion — use that. But when the failure is internal to the application with no better classification, 500 is correct.

One critical distinction: a 500 does not mean the server is down. A server that is fully offline would produce a TCP connection error or a 502/503 from the load balancer or CDN in front of it. A 500 means the server is alive and the request reached it — the application just crashed processing it.

Common causes

Unhandled application exception

The most frequent cause. A code path reached a state the application did not handle — a null pointer, a failed type assertion, a division by zero, an array index out of bounds. The framework catches the exception at the top level and returns 500. The specific error is in the application log as a stack trace.

Database connection failure or query error

The application could not connect to the database, the connection pool was exhausted, or a query returned an unexpected error. Applications that do not handle database errors gracefully will bubble them up as 500. Check database connection limits, query timeouts, and whether the database host is reachable from the application server.

Bad deployment or failed migration

A newly deployed version introduced a regression, or a database migration changed a schema the old or new code did not expect. 500s that appear immediately after a deployment are almost always a regression or migration issue. Rollback and investigate before re-deploying.

Missing or invalid environment variable

An API key, database URL, or service endpoint is absent or malformed. The application attempts to use it and fails. These failures are often silent during local development (where .env files are present) and surface only in production or staging environments where variables must be explicitly set.

Dependency timeout not handled

A downstream API, cache, or microservice did not respond within the configured timeout, and the application code did not handle the timeout exception. The request terminates as a 500 rather than a graceful error response. Add timeout handling and consider circuit breaker patterns for external dependencies.

Out-of-memory or resource exhaustion

The process consumed available memory, file descriptors, or thread pool capacity. This type of 500 is intermittent and often correlates with traffic spikes or memory leaks. Check resource utilization metrics alongside the 500 rate.

Server misconfiguration

Web server configuration errors — wrong file permissions, missing document root, malformed rewrite rules — can cause 500 before the application code even runs. These typically appear in the web server error log (not the application log) and affect all requests to a path rather than specific code paths.

How to diagnose a 500 error

The single most important step is getting the stack trace. Without it, a 500 is nearly impossible to debug. The following steps assume structured logging is available:

1. Check the application error log. The exception that caused the 500 should be logged with a full stack trace. If you use structured logging, filter by the request ID or timestamp from the failed request. The stack trace points to the exact file and line number that threw the error.
2. Correlate with recent deployments. If the 500s started after a deploy, the cause is almost certainly a regression in that deploy. Check the diff, roll back if needed, and investigate in a lower environment.
3. Check upstream dependencies. Query your database, cache, and downstream services directly to confirm they are healthy. A 500 triggered by a database outage looks the same in HTTP as one triggered by a code bug — the application log is the only way to tell the difference.
4. Reproduce in isolation. Identify the specific request (URL, method, headers, body) that produces the 500 and replay it in a non-production environment with verbose logging enabled. Many 500s are data-specific: they occur only for certain records, users, or inputs.
5. Check environment variables and configuration. Confirm all required variables are set in the environment where the 500 is occurring. Compare environment configuration between working and broken environments.
6. Review error monitoring dashboards. Tools like Sentry, Datadog, or Honeycomb group 500s by error type and show frequency trends. A spike in a specific exception class narrows the search considerably.

500 errors in production operations

A sustained 500 rate is an incident. A single intermittent 500 may be acceptable depending on the endpoint. The operational response differs by severity.

For a 500 that started immediately after a deployment: treat it as a rollback trigger. Do not try to forward-fix a broken deployment under load. Roll back, restore service, then investigate the cause offline.

For intermittent 500s that pre-date the last deployment: look for correlation with traffic volume (resource exhaustion pattern), specific users or data (code path bug), or time of day (scheduled job conflict or external API rate limit).

For 500s from a specific endpoint: add request/response logging to that endpoint, reproduce the failing case, and test the fix in a lower environment before deploying. If the endpoint is non-critical, consider temporarily returning a structured error response (still a 500) with a support reference ID while the fix is developed.

Note that search engine crawlers record 500 responses. Googlebot will re-attempt the URL but will eventually remove it from the index if 500s persist. A 500 on an important page is a crawl budget and indexation concern, not just a user experience issue.

500 vs 502 vs 503 vs 504

All four are server-side errors but they diagnose different things. Mixing them up wastes investigation time.

For a detailed comparison, see: 500 vs 502 · 500 vs 503 · 500 vs 504

SEO and crawler implications

Googlebot treats 500 responses as temporary failures. It will retry the URL after a delay and will not immediately remove it from the index. However, if a URL consistently returns 500 over an extended period (typically several weeks), Google will drop it from the index.

A 500 on a high-priority page is worth treating urgently from an SEO perspective — not just for users. If a landing page, guide, or important reference URL starts returning 500, the crawl budget wasted on retrying it compounds with the eventual deindexation risk.

Unlike 410 Gone, a 500 does not signal permanent removal. Google will continue retrying 500 URLs indefinitely. Once the underlying issue is fixed, the URL typically returns to the index at the next crawl without needing to be resubmitted.

FAQ

Does a 500 error mean my server is down?

No. HTTP 500 means the server is running and received your request, but something in its own code or dependencies prevented it from completing the response. A server that is fully down would show a connection refused error or a 502/503 from a gateway in front of it.

Should clients retry on a 500?

Only for idempotent requests (GET, HEAD, OPTIONS, PUT, DELETE). Never automatically retry POST or PATCH requests on 500, as they may have already been partially processed. Use exponential backoff with a retry limit rather than immediate retries.

What is the difference between 500, 502, 503, and 504?

500 is a generic application-level failure. 502 means a proxy got an invalid response from your app server. 503 means the server is intentionally refusing requests. 504 means a proxy timed out waiting for your app server.

How do I find the cause of a 500 error?

Start with the application error log. The server should log a stack trace when an unhandled exception occurs. If logs are unavailable, check your error monitoring tool, correlate the timestamp with recent deployments, and check upstream dependency health.

Can a 500 error be cached?

500 responses should not be cached. Caching a 500 would serve the error to subsequent users even after the underlying issue is fixed. Configure your CDN to never cache 5xx responses.

Related resources

On this site: HTTP 500 debugging and prevention guide · HTTP 502 Bad Gateway · HTTP 503 Service Unavailable · HTTP 504 Gateway Timeout · All 5xx server errors

Comparisons: 500 vs 502 · 500 vs 503 · 500 vs 504 · 508 vs 500

Standards: RFC 9110 §15.6.1 · IANA HTTP Status Code Registry · MDN Web Docs: 500