503 Service Unavailable

503 Service Unavailable means the server is temporarily unable to handle the request — it exists, it's just overloaded, starting up, or deliberately down for maintenance. "Temporary" is the defining trait, and a well-behaved 503 includes a Retry-After header saying when to come back.

The two faces of 503

• Overload — request queues full, worker pool exhausted, a dependency down and the server shedding load. Involuntary.
• Maintenance — you chose to return 503 during a migration. Correct and SEO-safe: search engines treat a 503 with Retry-After as "come back later" and don't de-index (a maintenance page returning 200 risks getting indexed as your content; one returning 404 risks de-indexing).

Common causes

• Autoscaling lag — traffic spiked faster than instances could start
• Health checks failing — load balancers take backends out of rotation when their health endpoint 503s; if all backends fail the check, the LB itself serves 503 to everyone. A too-strict health check (e.g. failing on a slow but non-critical dependency) can down a healthy fleet.
• Dependency circuit breakers — the app shedding load because a database or downstream API is struggling
• Worker exhaustion — every PHP-FPM/Puma/gunicorn worker busy; requests queue and then 503
• Cloud platform limits — serverless concurrency caps hit

Debugging

Look at scope first: one endpoint 503ing points at its specific dependency; everything 503ing points at load balancer health checks or global capacity. Then look at timing: rush-hour 503s are capacity, deploy-time 503s are readiness probes passing before the app can actually serve.

During planned maintenance, use maintenance windows so your own monitoring doesn't page the on-call about downtime you scheduled — alerts are suppressed and the window is excluded from uptime statistics. Outside maintenance, a 503 is exactly what an HTTP monitor should page about: capacity problems compound quickly.