HTTP 503 Service Unavailable
HTTP 503 Service Unavailable means the server is temporarily unable to handle the request. Unlike 500 Internal Server Error, 503 is typically an intentional, controlled state — the server knows it cannot serve traffic and is explicitly signaling this to clients and load balancers.
Quick reference
| Code | 503 |
|---|---|
| Name | Service Unavailable |
| Category | 5xx Server Errors |
| Specification | RFC 9110 §15.6.4 |
| IANA status | Assigned |
| Retry-After | Should be included when the unavailability is time-bounded |
| Client behavior | Respect Retry-After if present. Implement exponential backoff. Do not hammer a 503 server. |
| Caching | Should not be cached unless a specific Cache-Control or Expires header is present. |
| In-depth guide | HTTP 503 troubleshooting and recovery guide → |
What it means
503 is the correct response for a server that knows it cannot service traffic. This distinguishes it from 500 (unexpected failure) and from a TCP connection error (server is completely unreachable). A 503 means the server is reachable, capable of responding, but is deliberately declining requests.
Common scenarios where 503 is the right choice: planned maintenance windows, server overload where accepting more traffic would worsen the situation, health check failure where a server is instructing a load balancer to stop routing traffic to it, and graceful shutdown during a rolling deployment.
503 and load balancer health checks
Load balancers and service meshes poll backend servers with health check requests. A server returning 503 for health check probes signals to the load balancer that it should be removed from the rotation. This is a deliberate operational pattern — servers return 503 to drain gracefully before shutdown rather than abruptly dropping connections mid-request.
Common causes
Server overload
The server's capacity is exceeded. Accepting more requests would make the situation worse, so the server actively sheds load by returning 503. Proper autoscaling, rate limiting, and load shedding should prevent uncontrolled overload.
Planned maintenance
The server is intentionally taken offline for maintenance. 503 with a Retry-After header indicating the maintenance window end time is the correct pattern.
Dependency failure
A critical dependency (database, authentication service, cache) is unavailable and the server cannot function without it. Depending on the architecture, returning 503 may be more appropriate than 500 because the server itself is operational but cannot complete requests.
Graceful shutdown during deployment
A server in the process of shutting down for a rolling deployment returns 503 to signal to the load balancer to stop sending new requests. In-flight requests are completed; new ones are rejected.
503 vs 500 vs 502 vs 429
| Code | Cause | Intentional? | Retry? |
|---|---|---|---|
| 503 | Server consciously rejecting traffic | Yes | Yes — after Retry-After |
| 500 | Unexpected server-side failure | No | Yes — idempotent requests only |
| 502 | Proxy received invalid upstream response | No | Yes — if transient |
| 429 | Client-specific rate limit | Yes | Yes — after Retry-After |
See also: 500 vs 503 · 429 vs 503 · 502 vs 503
SEO implications
Google treats 503 as a temporary signal. Googlebot will retry 503 URLs and will not immediately drop them from the index. For planned maintenance, a properly implemented 503 with Retry-After is SEO-safe: Google recognizes the pattern and waits before re-attempting. Extended 503s (several days) can cause ranking drops as Google marks the page as temporarily unavailable.
For planned maintenance pages: return 503, include Retry-After with the expected end time, and serve an informative HTML page (not just a blank response). This signals to Google that the maintenance is planned and time-bounded.
Related resources
On this site: HTTP 503 troubleshooting guide · HTTP 500 Internal Server Error · HTTP 502 Bad Gateway · HTTP 429 Too Many Requests · All 5xx server errors
Comparisons: 500 vs 503 · 429 vs 503 · 502 vs 503 · 503 vs 504
Standards: RFC 9110 §15.6.4 · IANA Registry · MDN Web Docs: 503