What causes a 503 error (and what to do)

Deliberate or accidental?

503 is unusual among error codes: it is the one servers send on purpose. That makes the first diagnostic question different from its neighbours. A 500 is never intended and a 502 means something upstream broke — but a 503 might be your own maintenance page doing exactly its job, or it might be your server drowning. Work out which before you touch anything.

A quick tell: deliberate 503s tend to be instant and consistent (every request, right away, often with a styled maintenance page). Accidental ones tend to be slow and patchy — some requests succeed, others hang and then fail, because the server is struggling rather than declining.

The usual causes

• Overload. More requests than the server can handle — a traffic spike, a viral link, or a crawler hammering you — so it sheds load by refusing some visitors.
• Maintenance mode. Deploys and upgrades often serve 503 intentionally for a few seconds or minutes. Correct behaviour — until it outlives the maintenance.
• Rate limiting. The server (or a service in front of it) decided one client is asking too often and is turning that client away while serving everyone else.
• Autoscaling lag. On cloud platforms, traffic arrives instantly but new capacity takes minutes to spin up. The gap between the two is served as 503s.
• WordPress maintenance, stuck. WordPress creates a .maintenance file during updates and deletes it when done. If the update dies partway, the file stays — and the site serves “Briefly unavailable for scheduled maintenance” indefinitely until you delete that file from the site root.

Retry-After: the polite 503

A well-behaved 503 includes a Retry-After header — the server saying “come back in 120 seconds” or “after this timestamp.” Browsers don't show it, but search engine crawlers respect it, which is why a maintenance window served as a proper 503-with-Retry-After does not hurt your rankings the way an error page pretending to be a 200 can. If you are checking your own site, the presence of that header is strong evidence the 503 is deliberate.

If it's your website: what to do

1. Check whether anything is meant to be running. A deploy, an update, a backup job? If yes, the 503 may be maintenance mode working as designed — the problem is only if it persists after the job finished.
2. On WordPress, look for the .maintenance file. If an update ran recently and the site is stuck, deleting that one file from the site root brings it back immediately.
3. Look at server load. CPU pegged, memory exhausted, or a worker pool at its ceiling means genuine overload: restart what is wedged, add capacity, or block the traffic source that caused the spike.
4. Check anything that sits in front of your app. CDNs, load balancers and hosting platforms all emit their own 503s when they think your origin is unhealthy — their status pages and dashboards will say so.
5. If it is patchy and load-driven, wait it out deliberately — but note the time and what traffic caused it. A 503 that clears on its own will come back on the next spike unless something changes.

If you're a visitor

A 503 is the most retry-friendly error there is: the site is telling you it exists and expects to be back. Wait a minute or two and try again. There is nothing to fix on your end — though if one site 503s you specifically while working for others, you may have hit a rate limit, and slowing down is the fix.

Telling 503s apart from real downtime

Because 503s are often brief, they are easy to miss and easy to misread — a site can shed visitors at every traffic peak while looking fine each time the owner checks. The way to see what is really happening is to read the actual status code and headers at the moment of failure, and to check repeatedly over time rather than once.