HTTP Server Error Status Codes (5xx)
Guide to 5xx server error responses: diagnosing 500, 502, 503, 504 errors, retry strategies, and monitoring.
A guide to 5xx server-error codes (500, 501, 502, 503, 504, 507 and 511) with causes, diagnosis steps, what a client should do and what a server owner should fix, plus a retry strategy and monitoring metrics.
Use it when
- You are diagnosing a 5xx response or deciding how clients should retry.
- You are defining monitoring for server errors.
Watch out for
- 5xx codes do not say whether a request had effects; retry only idempotent requests or use idempotency keys.
- Retries without backoff and jitter can turn a partial outage into a full one.
The data
Server errors
7 rows
| Code | Name | Cause | Diagnosis | Client action | Server fix | Example |
|---|---|---|---|---|---|---|
| 500 | Internal Server Error | Generic server-side error; unhandled exception, unexpected condition. | Check application logs, stack traces, error monitoring (Sentry, Datadog). Common causes: null pointer, DB connection failure, unhandled promise rejection. | Retry after delay (exponential backoff). If persists, contact support with request ID/timestamp. | Add error handling, validate inputs, ensure resources available, catch exceptions | null |
| 501 | Not Implemented | Server does not support the functionality required to fulfill the request. | Check API documentation; endpoint may be planned but not released | Use alternative endpoint or method; check docs for supported operations | null | Method not implemented (POST on endpoint that only supports GET), feature flag disabled |
| 502 | Bad Gateway | Server acting as gateway/proxy received invalid response from upstream server. | Check upstream service health, connectivity, response format; inspect proxy logs | Retry after short delay (upstream may be temporary); if persistent, contact API provider | null | Nginx proxy to PHP-FPM got malformed response, API gateway to microservice got 404/invalid JSON |
| 503 | Service Unavailable | Server temporarily unable to handle request due to overload or maintenance. | Check server load (CPU/memory), connection pool exhaustion, deployment status | Retry with exponential backoff (e.g., 1s, 2s, 4s, 8s); check status page for known outage | Scale resources, enable connection queuing, implement graceful degradation, schedule maintenance windows | Too many concurrent connections, server restarting, maintenance mode, auto-scaling cold start |
| 504 | Gateway Timeout | Gateway/proxy did not receive timely response from upstream server. | Check upstream service latency, database query performance, network connectivity, timeout configurations | Retry with longer delay (upstream may need recovery); consider breaking request into smaller chunks | null | Nginx proxy timeout after 60s, API gateway upstream slow query (>30s), slow third-party API |
| 507 | Insufficient Storage | Server unable to store representation (disk full, quota exceeded). | Check disk space (`df -h`), inode usage, storage quotas, cleanup old files | null | Increase storage, implement cleanup policies, add monitoring alerts for disk space | Upload fails because disk full, user storage quota exceeded, temp directory full |
| 511 | Network Authentication Required | Client needs to authenticate to gain network access (captive portal, proxy auth). | Check if behind captive portal; client should redirect user to login page | Open browser to authenticate; client libraries should handle 511 by showing login URL | null | Wi-Fi hotspot login page, corporate proxy requiring credentials |
Retry strategy
- Exponential backoff
- Wait = min(2^n * base, max_delay) where n = attempt number (starting at 0)
- Example config
- Initial delay ms
- 1000
- Max delay ms
- 60000
- Multiplier
- 2
- Max retries
- 5
- Jitter
- Add random ±10-25% to prevent thundering herd
- Idempotency
- Only retry idempotent methods (GET, PUT, DELETE, HEAD, OPTIONS); POST should be retried only with idempotency key
Monitoring metrics
- Error rate percentage (5xx / total requests)
- P99/P95 latency of error responses
- Upstream service health checks
- Server resource metrics (CPU, memory, disk, connections)
- Circuit breaker state (open/closed/half-open)
Fields
The shape of this dataset, read from the data itself: every column, its type and a real value. Agents can use this to plan a query without fetching the whole document.
| Section | Field | Type | Example |
|---|---|---|---|
| server_errors | code | integer | 500 |
| server_errors | name | string | Internal Server Error |
| server_errors | cause | string | Generic server-side error; unhandled exception,… |
| server_errors | diagnosis | string | Check application logs, stack traces, error mon… |
| server_errors | client_action | string | Retry after delay (exponential backoff). If per… |
| server_errors | server_fix | string | Add error handling, validate inputs, ensure res… |
| server_errors | example | string | Method not implemented (POST on endpoint that o… |
| retry_strategy | * | object | {exponential_backoff,example_config,jitter,idempotency} |
| monitoring_metrics | * | array | [5 items] |
Fetch the same bytes
The static files contain the same reference rows as the API, with no API rate limit. Live metadata, such as view counts, may differ. Use the API for content negotiation; use the static files for a cacheable snapshot.
curl "https://yjtoon.yunusemrevurgun.com/api/dataset/http-server-error-guide?format=toon"
const res = await fetch( "https://yjtoon.yunusemrevurgun.com/static-data/dataset/http-server-error-guide.toon" ); const toon = await res.text();
Rate limit: 120 requests per minute per IP, no key and no signup. API reference →