HTTP 5xx Server Errors: Meaning, Diagnosis and Fixes

What this error means & how to recognize it

You may see one or more of these symptoms:

• A website or API returns an HTTP status from 500 through 599.
• The response is a generic server error, an application error, or a branded reverse-proxy, load-balancer or CDN page.
• Only one route, operation or API endpoint fails while other pages continue to work.
• The entire service becomes unavailable or intermittently returns errors.
• Requests become slow before ending with a 504 or another gateway-related 5xx response.
• The response includes a request ID, upstream identifier or server-specific error header that can help identify the generating layer.

Root causes, ordered by likelihood

Likely causes, from common to less common, include:

1. Application exceptions or failed request handling. Unhandled application errors, invalid input paths or a faulty code change can produce a 500 response.
2. Recent deployment or configuration changes. A release, environment-variable change, routing change or server configuration error may affect one route or the whole service.
3. Unhealthy backend processes. A stopped, crashing, overloaded or unreachable application process can cause a proxy to return 502 or 503.
4. Dependency failures. Database errors, unavailable internal services, slow external services or exhausted connection pools can surface as several different 5xx codes.
5. Timeouts between layers. A gateway may return 504 when an upstream service does not respond within the configured timeout; slow dependencies can be the underlying cause.
6. Resource pressure. High CPU or memory use, worker saturation, disk exhaustion or connection limits can make a service unavailable or cause requests to time out.
7. Maintenance or intentional protection. A service may return 503 while it is being maintained, drained, rate-limited or protected from overload.
8. Layer-specific status behavior. The same underlying incident can produce different codes depending on whether the application, web server, reverse proxy, load balancer or CDN generated the response.

How to fix it

1. Capture the failure precisely

Record the exact status code, affected URL or API operation, time including time zone, frequency, response body and relevant response headers. Preserve any request ID or trace ID. If you are only visiting the site, send these details to the service owner rather than changing server settings.

2. Identify the response-generating layer

Compare the error page or JSON body, headers, cookies and server identifiers with a known successful response. A framework-specific error body may point to the application; a gateway- or CDN-branded page may mean the request failed before the origin produced a response. Check reverse-proxy, load-balancer or CDN logs when origin logs contain no matching request.

3. Separate a broad outage from a route-specific failure

Test an approved, low-impact health endpoint and a known unaffected route. If only one route fails, inspect its application code, data access and request-specific dependencies. If every route fails, prioritize process health, deployment state, routing, capacity and shared dependencies. Do not repeatedly refresh a production endpoint as a substitute for a health check.

4. Correlate logs at the same timestamp

Review application, web-server, proxy/load-balancer and dependency logs together. Search for the request ID first, then narrow by timestamp and endpoint. Look for stack traces, process restarts, connection-refused messages, upstream status codes, timeout messages, failed database calls and rejected connections. Sanitize credentials, tokens and sensitive request data before sharing logs.

5. Check recent changes and service health

Review deployments, feature flags, configuration changes, certificate or routing updates, maintenance activity and dependency changes made shortly before the failures began. Confirm that backend processes are running and passing their health checks. If a recent change is strongly correlated with the incident, use the service's approved rollback procedure and authorization; do not restart or roll back production systems without operational approval.

6. Check dependencies and resource pressure

Inspect database reachability and latency, internal service health, external dependency responses, connection-pool usage, queue depth, CPU, memory, disk space, worker availability and connection limits. A dependency that is merely slow can cause a 504 even when the application process itself is running. Correct the constrained or failing component rather than masking the symptom by increasing timeouts blindly.

7. Use the status code to focus the investigation

• 500 Internal Server Error: Start with application logs, server errors, the failing route and recent code or configuration changes.
• 502 Bad Gateway: Inspect the proxy-to-upstream connection and the upstream response. Check whether the backend is down, closing connections, returning malformed data or being reached through an incorrect route.
• 503 Service Unavailable: Check maintenance state, readiness or health checks, overload controls, process availability and shared dependencies.
• 504 Gateway Timeout: Measure where time is spent. Check upstream latency, database or external calls, connection pools and timeout settings across each layer.
• Other 5xx statuses: Use the exact status definition and the component that emitted it; do not assume that every 5xx response has the same cause.

8. Apply the narrowest authorized fix and verify safely

Fix the identified application, configuration, dependency or capacity issue using the environment's change-control process. Afterward, verify a simple health endpoint, the previously failing operation and representative dependent functions. Confirm that 5xx rates and latency have returned to normal without creating duplicate writes or additional load. If the fix involves a state-changing action such as restarting a process, draining traffic or changing a timeout, document the expected impact and obtain authorization first.

Prevention & how to verify the fix

• Monitor 5xx rate, latency and availability by route, service and response-generating layer.
• Use readiness and liveness checks that reflect real dependency requirements without creating excessive load.
• Keep request IDs or trace IDs consistent across proxies, applications and dependencies.
• Set bounded, reviewed timeouts and connection limits at each service boundary; avoid allowing slow external calls to consume all workers.
• Alert on resource saturation, process crashes, database latency, connection-pool exhaustion and disk pressure before they become widespread failures.
• Use staged deployments, health-based traffic shifting and a tested rollback procedure.
• Document which 5xx codes each proxy, application and dependency can emit so responders do not treat 500, 502, 503 and 504 as interchangeable.
• Regularly test degraded-dependency and overload behavior in an authorized environment.

Frequently asked questions