What 503 promises, and what it does not
A 503 is the server saying "I exist, I understood you, come back later". Unlike a 500 it does not claim anything broke, and unlike a 502 it is not about a failed conversation with a machine further back. It is a refusal with an implied "for now".
That "for now" is why 503 is the right code for planned maintenance and for overload, and the wrong code for anything permanent. Search engines treat it as temporary and will come back, which is exactly what you want during a deploy and exactly what you do not want on a page you have retired — that one is a 410 or a 301.
Cause 1 — the origin is out of capacity
Every server has a ceiling on concurrent work: PHP-FPM children, application workers, database connections. When the ceiling is reached, a well-configured stack refuses new work quickly with a 503 instead of accepting it and timing out. That is the system behaving correctly under pressure, even though it looks like a failure.
How to recognise it. The 503s track traffic: they appear at peaks and clear when the peak passes. Your origin is up the whole time and responds instantly to a request you make from a quiet moment.
What actually helps. Raising worker counts moves the ceiling and usually moves the bottleneck to memory or the database. The durable fix is to stop sending repeat work to the origin at all: cache the pages that can be cached, give them a TTL long enough to matter, and let the edge absorb the peak. A campaign that melts an origin at 200 requests per second is often 195 requests for the same handful of pages.
Cause 2 — maintenance mode
Deploy tooling and CMS plugins put the site behind a maintenance page and return 503 while they work. This is correct behaviour and the code is the right one.
Two things go wrong with it. The first is a maintenance mode that never gets cleared — a failed deploy leaves the flag file in place and the site serves 503 long after the work finished. The second is a maintenance page served with a 200, which tells crawlers the maintenance notice is your actual content and is worth indexing.
If maintenance mode is on for more than a few minutes, add a Retry-After header. It costs one line and it is the difference between a crawler backing off politely and a crawler deciding your site is unreliable.
Cause 3 — a rate limit rejected the request
Rate limiting refuses requests that arrive faster than the configured threshold. Depending on the software and its configuration, the rejection arrives as 429 Too Many Requests or as 503 — nginx, for instance, refuses rate-limited requests with 503 unless it is told to use another code.
This matters when you are reading logs: a burst of 503s that affects one client, one path, or one user agent, while everything else is served normally, is a rate limit doing its job rather than a capacity problem. The fix is to look at who is hitting the limit. If it is a scraper, the limit is working. If it is your own mobile app polling an endpoint every second, the limit is correct and the app is wrong.
Cause 4 — the edge has no origin for this hostname
This is the one that wastes an afternoon, and it has nothing to do with your server.
When a hostname's DNS points at a CDN edge but that hostname has not been configured on the edge — the account does not exist yet, the delivery hostname was not added, or a typo put the record on the wrong name — the edge has no origin to ask. It cannot return 502, because there was no failed conversation. It returns 503 with a page saying no service is configured for this domain.
The sequence that produces it is always the same: someone changes DNS first and finishes the panel configuration afterwards, or changes DNS for www while the hostname was added as the bare domain. The site "goes down" the moment DNS propagates, the origin is perfectly healthy, and the fix takes a minute once you stop looking at the wrong machine.
How to recognise it instantly. Read the error page rather than the status code alone. A CDN's "no service configured" page is unmistakable and it names the problem. Then check that the hostname in your panel matches the name in the DNS record exactly, including www.
What to send, and what visitors should see
If you are the one returning the 503, two things make it much less costly.
Send Retry-After. Either a number of seconds or an HTTP date. Crawlers honour it, well-written clients honour it, and it converts a refusal into a schedule.
Serve something human. The default proxy error page tells a visitor nothing and looks broken. A branded page with a sentence about what is happening is a very small amount of work for a large difference in how an incident is experienced.
And if the content is cacheable, a CDN can keep serving the cached copy while the origin is refusing — which is the difference between "the site was slow for ten minutes" and "the site was down for ten minutes".
503 Service Unavailable FAQ
Is 503 better or worse than 502?
It is more informative. A 503 is a deliberate refusal, so something in the path is working well enough to decide. A 502 means a conversation with the machine behind failed. In practice a 503 is more often a capacity or configuration matter you control, and a 502 more often a broken origin.
Does a 503 hurt my search rankings?
Not if it is genuinely temporary. Search engines treat 503 as "come back later", which is why it is the right code during maintenance. A 503 that lasts for days is a different matter: the pages will eventually be dropped. Add Retry-After so the crawler knows what to expect.
I get 503 right after pointing DNS at the CDN. What now?
Check the error page. If it says no service is configured for the domain, the hostname is not set up on the edge yet — the origin is not involved. Add the exact hostname in the panel, including or excluding www to match the DNS record, and the 503 clears as soon as the configuration reaches the edges.
Can I cache a 503?
You should not, or only for seconds. A cached 503 keeps refusing visitors after the cause is gone. Serve error responses with a very short TTL and purge the path once the fix is in.
How do I stop 503s under load without a bigger server?
Reduce what reaches the origin. Cache what is cacheable with a TTL that survives a traffic spike, make sure the cache key is not fragmented by tracking parameters, and keep rate limits on the endpoints that attract automated traffic. A bigger server raises the ceiling; caching removes most of the requests that were pushing against it.