503 Service Unavailable (you'll also see "503 Service Temporarily Unavailable") means the server is up but can't take your request right now. It's a 5xx server code, but unlike a 500, it's explicitly temporary — the server is telling you to come back.
What causes a 503
| Cause | What's happening |
|---|---|
| Overload | More traffic than current capacity can serve |
| Maintenance mode | The app is intentionally taken offline |
| Resource limits | Out of workers, memory, or DB connections |
| Scaling lag | Autoscaling hasn't caught up with a spike |
| Dependency down | A required service (DB, cache, API) is unavailable |
| Rate limiting at the edge | A load balancer shedding load under stress |
503 vs 502 vs 500
- 503 → "I'm up but temporarily can't serve you" (overload/maintenance).
- 502 → "A server I depend on gave me an invalid response."
- 500 → "Something in my code threw an unexpected error."
How to fix it — as a visitor
- Wait a minute and reload — 503 is temporary by design.
- If a
Retry-Afterheader is present, that's how long to wait. - If it persists for hours, the site has a real capacity or outage problem.
How to fix it — as a developer
- Is it maintenance? Check whether maintenance mode or a deploy flag is on.
- Check capacity. CPU, memory, worker count, and DB connection pool under the current load.
- Scale. Add instances/workers; confirm autoscaling thresholds aren't set too high to react in time.
- Check dependencies. A maxed database or a downstream API often surfaces as 503 at your edge.
- Send a
Retry-After. It keeps clients (and crawlers) from hammering you while you recover.
Know before your users do
A 503 during a traffic spike or a botched deploy is exactly when minutes matter. Nurbak Watch checks your endpoints every minute from multiple regions and alerts you on a 503 spike via Slack, email or WhatsApp — so you're scaling up before the support tickets arrive.