HTTP 503 Service Unavailable: Overload, Maintenance, Fixes

Aug 04, 2026 · HTTP Status Codes

Of all the 5xx errors, 503 is the odd one out: it's the only one you will ever configure deliberately. Every other server error is an accident being reported; the 503 status code is frequently a plan being communicated. It means "I'm temporarily unable to handle this — try again later," and that message covers two situations that could not feel more different at 3am: a maintenance window you scheduled, and an overload you didn't.

Understanding both faces — and keeping them from blurring together — is most of what there is to know about this code.

The two faces of the 503 status code

Face one is planned unavailability. You're migrating a database, upgrading the platform, or deploying something that can't be done live. The honest response during that window is 503, because it tells every client — human or bot — that this is temporary and the resource still exists. Returning a 200 with a "we'll be back soon" page is actively harmful: crawlers index your maintenance page as if it were your content.

Face two is unplanned overload. The server is up but can't take more work: connection queues full, worker pools saturated, a dependency timing out, or a load balancer with zero healthy backends. Many stacks emit 503 automatically in these states — nginx returns it when a rate or connection limit trips, load balancers return it when every upstream fails health checks. Same status code, completely different investigation.

Sending a proper maintenance 503 with Retry-After

A maintenance 503 has three requirements. First, the actual status code — not a styled page riding on a 200. Second, a Retry-After header telling clients when to return, either in seconds (Retry-After: 3600) or as an HTTP date. Third, coverage of every URL, not just the homepage, so crawlers hitting deep pages get the same signal.

In nginx, a maintenance flag file makes this clean: check for the file's existence, and if present return 503 with the header set via add_header Retry-After 3600 always; and an error page for humans. Flipping maintenance on and off becomes touch /etc/nginx/maintenance.flag and rm — no config reloads mid-migration. Verify from outside with curl -sI https://yoursite.com/any-page/ and confirm both the 503 and the Retry-After line before you start the risky work.

Googlebot treats this exact combination as "pause and resume": it stops crawling, keeps your pages indexed, and returns later. For a window of hours, the SEO cost is essentially zero. That grace has a shelf life, though — stretch a 503 across many days and Google starts treating it as a real outage, reducing crawl and eventually dropping URLs, the same trajectory as any persistent 5xx.

When 503 means real trouble: overload and dependencies

Unplanned 503s cluster around a few causes. Genuine traffic overload — a launch, a viral link, a promotion — where demand simply exceeds capacity. Bot floods, where the "traffic spike" is scrapers or an attack rather than customers; the fix is filtering, not scaling, and it overlaps with the territory covered in our 429 guide. Dependency saturation, where the app is fine but everything is queued behind a database that's stopped keeping up — the 503 is the symptom, the slow query is the disease. And zero healthy upstreams: a load balancer whose health checks are failing every backend serves 503 for the whole pool, which sometimes means every app server is truly down and sometimes means the health check endpoint itself broke while the apps are fine. Always check which of those two it is before restarting anything.

How Google reacts to a 503

Google's crawl behavior around 503 is graduated and fairly well documented. On first contact, a 503 is the gentlest possible server error — explicitly understood as temporary, with Retry-After read as a scheduling hint. Persist for days and Googlebot cuts your crawl rate to avoid adding load, which delays indexing of everything new. Persist for weeks and URLs start dropping out of the index. The practical rule: a 503 measured in hours is free; one measured in weeks costs rankings. If a maintenance project will genuinely take that long, serve reduced functionality on a 200 instead of a long-running 503. And remember that crawl rate lost to error responses is crawl rate not spent on your actual content — the mechanics of that trade-off are covered in our crawl budget guide.

Diagnosing unplanned 503s

1. Find the emitter. A 503 can come from the CDN, the load balancer, nginx, or the app itself, and each points to a different failure. Response headers usually carry fingerprints (a Server: header, CDN-specific headers). Emitter identified is half the diagnosis done.
2. Check upstream health as the balancer sees it. Zero healthy backends at the LB means either dead apps or a broken health check. Hit the health endpoint by hand from the LB's network position.
3. Look at queue depths and limits. nginx connection limits, PHP-FPM's listen backlog, database max_connections — a 503 from a limit names the resource that ran out.
4. Classify the traffic. Pull the top client IPs and user agents from the access log for the incident window. If the load is a handful of IPs requesting expensive pages in a loop, you have a bot problem wearing an overload costume.

Keeping 503s short and rare

For the planned kind: script the maintenance flag, keep windows tight, schedule during your traffic trough, and always verify the Retry-After header actually goes out. For the unplanned kind: capacity headroom (if normal load runs your servers at 85%, any spike is an outage waiting), autoscaling or graceful degradation for the expensive parts of the site, bot filtering at the edge, and health checks that test something real without being so strict they fail the whole pool over a hiccup. Above all, know about 503s before your visitors tell you. Monitor your uptime from outside your own infrastructure — a check that hits your site every minute turns "we were down all night" into a five-minute incident. Serious dependency failures have a way of escalating from 503 to the harder-to-untangle errors in our 500 guide, and early warning is the difference.