---
title: 503 Service Unavailable
description: What HTTP 503 means, the overload-vs-maintenance distinction, Retry-After, and why health checks returning 503 take servers out of rotation.
canonical: https://watchfor.io/docs/reference/http-status-codes/503
---

# 503 Service Unavailable

What HTTP 503 means, the overload-vs-maintenance distinction, Retry-After, and why health checks returning 503 take servers out of rotation.

**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](/docs/monitors/maintenance) 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](/docs/monitors/web) should page about:
capacity problems compound quickly.

---

Canonical page: https://watchfor.io/docs/reference/http-status-codes/503 · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt