HTTP 500 Internal Server Error

HTTP 500 Internal Server Error is the generic server-side error indicating the server encountered an unexpected condition that prevented it from fulfilling the request. This is the 'catch-all' for unhandled exceptions, programming errors, and unexpected failures. Unlike specific 5xx codes (502, 503, 504), a 500 means the problem is in the server's own code or configuration, not in an upstream service or temporary condition. The error response should never expose stack traces or internal details in production.

Debug HTTP 500 live
Analyze real 500 behavior — headers, caching, CORS, redirects
Open Inspector →

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

Simulator URL (copy in the app after load — not a normal link):

https://httpstatus.com/api/status/500

Example request:

curl -i "https://httpstatus.com/api/status/500"
Try in playground

Meaning

A generic error message, given when an unexpected condition was encountered.

What it guarantees
  • The server (or an upstream) failed to fulfill a valid request.
What it does NOT guarantee
  • The failure is permanent.
  • Immediate retries are always safe or effective.

When to use this status

  • Unhandled errors or bugs in request handling.
  • Upstream dependency failures.
  • Timeouts, overload, or infrastructure instability.

When NOT to use this status (common misuses)

Returning 5xx for client validation errors.
Clients retry unnecessarily; traffic spikes and costs increase.
Returning 500 without stable error identifiers/correlation.
SRE triage slows down; alerting becomes noisy and hard to act on.
Returning 503/504 without retry guidance.
Clients hammer the service or give up too early; cascading failures worsen.

Critical headers that matter

Content-Type
Defines error body format (JSON/text/problem+json).
Clients can’t parse structured errors; observability loses fidelity.
Cache-Control
Prevents caching transient errors unless intended.
CDNs cache failures; prolonged user-visible outages.

Tool interpretation

Browsers
Displays an error state; devtools exposes status and headers. Cache headers can accidentally cache error documents.
API clients
Classifies as failure; retry policy depends on idempotency and code class. Structured errors improve handling.
Crawlers / SEO tools
Persistent failures reduce crawl rate; soft-404 patterns cause indexing instability.
Uptime monitors
Typically alerts based on rate/threshold. Consistent classification reduces false positives.
CDNs / reverse proxies
May cache errors if misconfigured; respects Cache-Control and can serve stale on origin failure.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
  • Error cacheability and retry guidance signals
Correctness warnings
No common correctness warnings are specific to this code.

Guided Lab outcome

  • Reproduce HTTP 500 Internal Server Error using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).
  • Learn to attribute failures to origin vs upstream and apply safe retry/backoff decisions.

Technical deep dive

HTTP 500 Internal Server Error represents a server-side failure that requires different handling than other 5xx errors. Understanding the precise cause helps operations teams diagnose and resolve issues faster. The server should log the full error details internally while returning a sanitized error to the client.

Real-world examples

Production 500 Internal Server Error incident
A production system returns 500 Internal Server Error. The operations team triages based on the specific status code: unhandled exception in application code.
Load balancer returning 500
A load balancer returns 500 to clients. For 500 specifically, this typically indicates the backend returned an error.
Client retry logic for 500
A client receives 500 Internal Server Error. Retry with exponential backoff — the error may be transient.

Framework behavior

Express.js (Node)
Express: uncaught exceptions in route handlers result in 500 by default. Use error middleware: app.use((err, req, res, next) => { res.status(err.status || 500).json({ error: 'Internal Server Error' }); });
Django / DRF (Python)
Django: unhandled exceptions return 500 with DEBUG page in development, generic 500.html in production. Custom error views: handler500 = 'myapp.views.server_error'.
Spring Boot (Java)
Spring Boot: unhandled exceptions return 500 by default. Configure @ControllerAdvice for custom error responses. Actuator /health endpoint can trigger 503 when unhealthy.
FastAPI (Python)
FastAPI: unhandled exceptions return 500. Add exception handlers: @app.exception_handler(Exception) for custom 500 responses. Never expose stack traces in production.

Debugging guide

  1. Check server application logs for stack traces and unhandled exceptions
  2. Verify the error is reproducible — transient 500 errors may indicate intermittent issues like memory pressure or connection pool exhaustion
  3. Check recent deployments — a new deploy is the most common cause of sudden 500 spikes
  4. Review server resource utilization (CPU, memory, disk, connections)
  5. Test with curl -v to see the full response including headers — some 500 responses include diagnostic headers

Code snippets

Node.js
// Handle 500 Internal Server Error
process.on('unhandledRejection', (reason) => {
  console.error('Unhandled rejection:', reason);
});

app.use((err, req, res, next) => {
  console.error(`${req.method} ${req.url}:`, err.stack);
  res.status(err.status || 500).json({
    error: process.env.NODE_ENV === 'production'
      ? 'Internal Server Error'
      : err.message,
    requestId: req.id
  });
});
Python
from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse
import logging

logger = logging.getLogger(__name__)

@app.exception_handler(Exception)
async def server_error_handler(request: Request, exc: Exception):
    logger.error(f'{request.method} {request.url}: {exc}',
                 exc_info=True)
    return JSONResponse(
        status_code=500,
        content={'error': 'Internal Server Error', 'request_id': request.state.id}
    )
Java (Spring)
@ControllerAdvice
public class GlobalErrorHandler {
    private static final Logger log = LoggerFactory.getLogger(
        GlobalErrorHandler.class);

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleException(
            Exception ex, HttpServletRequest req) {
        log.error("{} {}: {}", req.getMethod(),
                  req.getRequestURI(), ex.getMessage(), ex);
        return ResponseEntity.status(500)
            .body(new ErrorResponse("Internal Server Error",
                "An unexpected error occurred"));
    }
}
Go
func errorMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		defer func() {
			if err := recover(); err != nil {
				log.Printf("%s %s: %v\n%s",
					r.Method, r.URL, err, debug.Stack())
				w.WriteHeader(500)
				json.NewEncoder(w).Encode(map[string]string{
					"error": "Internal Server Error",
				})
			}
		}()
		next.ServeHTTP(w, r)
	})
}

FAQ

What causes 500 Internal Server Error errors?
Unhandled exceptions, null pointer errors, failed database queries, misconfigured services, out-of-memory conditions, and any unexpected server-side failure.
Should clients retry on 500 Internal Server Error?
Yes, with exponential backoff. Transient failures often resolve on retry. Use jitter to avoid thundering herd. Limit retries (3-5 attempts max).
How should 500 Internal Server Error be monitored?
Track 500 error rate as a percentage of total requests. Alert on sustained rates above baseline (e.g., >1% for 5 minutes). Include error classification in dashboards to distinguish between different failure modes.
What information should a 500 response include?
In production: a generic error message, a request ID for correlation, and optionally a Retry-After header. Never include stack traces, internal paths, database errors, or configuration details. In development: full error details are acceptable. Always log the full error server-side with the request ID.

Client expectation contract

Client can assume
  • The server or an upstream failed to fulfill the request.
Client must NOT assume
  • Immediate retries are always safe or effective.
Retry behavior
Retry idempotent requests with backoff; avoid retries for non-idempotent writes unless you have idempotency keys.
Monitoring classification
Server error
Alert on rate and duration; ensure CDNs do not cache transient failures.

Related status codes

501 Not Implemented
The server either does not recognize the request method, or it lacks the ability to fulfill the request.
499 Client Closed Request
The client closed the connection before the server could send a response (non-standard, used by nginx).

Explore more

Related guides
Related tools
Related utilities