Your product gets featured somewhere big. Traffic pours in. And then, right at the worst possible moment, visitors start seeing 503 Service Unavailable. Your moment in the spotlight becomes an outage.
Unlike a 502 (where the upstream is dead), a 503 is almost optimistic: the server is alive and answering — it's just telling you it can't take this request right now. Let's unpack what that means and how to handle it.
What a 503 actually means
503 Service Unavailable is the server saying: "I'm here, but I can't serve you at this moment." It's a deliberate, temporary "not now" — not a crash. The two classic reasons:
- Overload — too many requests; the server is protecting itself by shedding load.
- Maintenance — the server is intentionally returning 503 while you do planned work.
502 vs 503, in a nutshell: a 502 means "the thing behind me is broken"; a 503 means "I'm fine, but I'm too busy or deliberately closed right now." One is an accident, the other is often on purpose.
The usual causes
| Cause | What's happening |
|---|---|
| Traffic spike | More requests than capacity; load shed as 503s |
| Maintenance mode | You're intentionally serving 503 during work |
| Resource exhaustion | Worker/connection pool full, nothing left to serve |
| Failing dependency | A backend it needs is down, so it refuses requests |
| Auto-scaling lag | Demand jumped faster than new capacity came online |
A useful detail: the Retry-After header
A well-behaved 503 often includes a Retry-After header telling clients (and search-engine crawlers) how long to wait before trying again. This matters for SEO: a 503 with Retry-After says "temporary, come back soon" — far better than letting crawlers think your pages are gone. If you serve maintenance pages, set it.
How to fix it
For an overload 503:
- Confirm it's load. Check CPU, memory, and your worker/connection pool — are they maxed out?
- Add capacity. Scale up/out if you can. This is what autoscaling is for.
- Shed smart, not hard. Cache aggressively, and protect the critical paths (checkout) over the optional ones.
- Find the bottleneck. Often it's not the web tier but a slow database or dependency behind it.
For a maintenance 503: just make sure it's intentional, scoped, and ends when the work does — and that it's announced on your status page.
502 vs 503 vs 504
The three 5xx codes people mix up:
| Code | Meaning | Shortcut |
|---|---|---|
| 502 Bad Gateway | Upstream gave an invalid/no response | App is dead |
| 503 Service Unavailable | Server up, can't serve now | Overloaded or in maintenance |
| 504 Gateway Timeout | Upstream too slow | App is slow |
How to prevent it
- Autoscaling so capacity follows demand — and warm up before a known spike (a launch, a campaign).
- Caching and a CDN to absorb traffic before it reaches your origin.
- Load testing so you know your ceiling before your customers find it.
- Graceful degradation — shed the non-essential, keep the core alive.
- Monitoring for 503 spikes, so you know the instant you're shedding load — ideally before the featured-launch crowd does.
The bottom line
| In one line | |
|---|---|
| What | Server is alive but can't serve right now. |
| Why | Overload, or deliberate maintenance. |
| vs 502 | 502 = dead upstream; 503 = too busy / closed. |
| Prevent | Autoscale, cache/CDN, load test, monitor. |
A 503 is your server being honest about its limits. Treat it as a capacity signal: add headroom, cache hard, and watch for it — so your big moment stays a triumph, not an outage.
More 5xx decoding in HTTP status codes explained; set up alerts with the web monitoring guide.