503 Service Unavailable
The server is deliberately refusing work right now: overloaded, in maintenance mode, or (behind a load balancer) with zero healthy instances. Unlike a 502's surprise failure, 503 is often a system protecting itself — and it should carry Retry-After.
What usually causes it
- No healthy backends passing health checks
- Explicit maintenance mode
- Overload shedding / connection limits reached
- Failing readiness probes in Kubernetes (app up but not 'ready')
How to debug and fix it
- Check the load balancer's healthy-host count first — zero healthy targets is the most common story.
- Read the health-check endpoint's actual response; apps often fail readiness for a dependency that is itself fine.
- Clients: honor Retry-After and back off — hammering a 503 deepens the overload.
- For planned maintenance, 503 + Retry-After is also the SEO-correct signal that content will return.
Easily confused with
Debugging an API? Build and inspect requests, check response headers, or read the full status-code debugging guide.