HTTP 500 Internal Server Error
HTTP 500 Internal Server Error is the production alarm everyone dreads. When your application returns 500, something on the server went wrong that it did not anticipate and could not handle gracefully. Users see an error page. Engineers see alert notifications. The question is always: what changed, and what is broken?
The most valuable tool for diagnosing 500s is your application logs — specifically the stack trace that the application should log when it catches (or fails to catch) the exception. Without a log, a 500 is nearly impossible to debug. Set up structured error logging with request IDs so you can correlate a user-reported 500 with the exact server-side error and context.
A 500 from a deployment is the highest priority rollback trigger. A 500 that correlates with database errors indicates a dependency failure. A 500 that only appears for specific users indicates a data-specific code path bug.
Quick reference
| Code | 500 |
|---|---|
| Name | Internal Server Error |
| Category | 5xx server errors |
| Specification | RFC 9110 |
| IANA status | Assigned |
| When to use | Use 500 as the default when no more specific 5xx code applies. Use 502 for gateway/proxy errors from upstream, 503 for deliberate unavailability, 504 for gateway timeouts. Do not use 500 for client errors — those are 4xx. |
| Client behavior | May retry after a delay (the server may recover). Automated clients should implement bounded retry with exponential backoff. After a threshold of retries, surface the error to the user or alert. |
| Caching | Not cached. |
Common causes
- Unhandled application exception
- Fatal error or application crash
- Server misconfiguration
- Database connection failure
- Failed deployment introducing a regression
How to fix it
- Check application logs for the full stack trace
- Inspect recent deployments for regressions
- Validate environment variables and configuration files
- Verify upstream services and database connections are healthy
- Set up error monitoring (Sentry, Datadog, etc.) to capture future occurrences
Example exchange
GET /api/data HTTP/1.1
Host: api.example.com
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{"error":"Internal server error"}When you see this in production
500 monitoring essentials:
- Alert on 500 rate rising above baseline (1-5% of requests is usually worth investigating)
- Correlate 500 spikes with recent deployments (most 500 incidents are deployment-related)
- Check database error rates and query latency alongside 500s (dependency failures are common root cause)
- Implement request IDs and structured logging so every 500 is traceable to a stack trace
- Monitor 500 distribution across endpoints — a 500 on one endpoint indicates application bug, 500 across all endpoints indicates infrastructure or dependency failure
What developers usually do next
- Debugging a 500:
- 1. Check application logs immediately — find the stack trace associated with the failing request
- 2. Identify the time of first occurrence and correlate with deploys
- 3. Check upstream dependencies: database connection pool, cache health, external API health
- 4. Reproduce locally with the same request if possible
- 5. If a deployment caused it: rollback first, investigate second
- 6. Add error monitoring (Sentry, Datadog APM, New Relic) if not already in place — 500s should never be "silent"
When NOT to use this code
Do not return 500 for client errors — those are 4xx. Do not let unhandled exceptions silently return 500 without logging the error. Do not use 500 for intentional unavailability (use 503) or for gateway/proxy failures (use 502).
Related status codes
HTTP 502 Bad Gateway · HTTP 503 Service Unavailable · HTTP 504 Gateway Timeout
Behind Cloudflare?
When your application crashes or returns a malformed response through a Cloudflare proxy:
Comparisons
HTTP 500 vs 502 · HTTP 500 vs 503 · HTTP 500 vs 504 · HTTP 500 vs 508
Frequently asked questions
Does a 500 error mean my server is down?
Not necessarily. A 500 means the server is running but encountered an error processing a specific request. A completely down server would typically show a connection error rather than a 500.
How do I debug a 500 error?
Start with server logs — the application should log the stack trace. If logs are unavailable, check error monitoring tools and recent deployment history.
Standards reference
This definition is derived from the IANA HTTP Status Code Registry and RFC 9110. Human-readable operational guidance by ErrorLookup. · HTTP 500 quick reference →