503 Service Unavailable

The 5xx codes are the server's errors, and four of them describe things going wrong. 503 is the odd one out. It means "I cannot handle this request at the moment, and I expect that to change" - Which is very often a considered decision by a healthy system rather than a symptom of a broken one.

The specification is explicit that the condition is temporary, and that a server which knows how temporary should say so with a Retry-After header. That header is the most underused piece of information in web error handling.

Three quite different situations

Planned maintenance

The correct way to take a service down deliberately is to return 503 with a Retry-After. It tells browsers, crawlers and API clients that this is temporary and they should come back - Crucially, it tells search engines not to deindex the page, which is what a 404 or a redirect during maintenance would eventually cause.

If a service you use goes offline on a schedule, this is usually what you are seeing. Telling maintenance from failure is often just a matter of reading the page.

Load shedding

When demand exceeds what a system can serve, it has two options: Try to serve everyone and collapse, or serve some people properly and refuse the rest. The second is better for everybody, and a 503 is how the refusal is expressed.

This is why you see 503s at a ticket sale, a game season launch, or a market open on a trading platform. The system is working exactly as designed. Queue pages and waiting rooms are the friendly version of the same mechanism - Login queues at a Fortnite season launch are capacity management, not failure.

Genuine unavailability

Occasionally a 503 does mean something is wrong: Every backend in a pool has failed health checks, a dependency is unreachable, or the application has shut itself down because it cannot reach its database. Here the 503 is honest but not deliberate.

Retry-After: Read it

The header comes in two forms - A number of seconds, or an HTTP date. Either way it is a real estimate from the server about when to come back.

For a human, this is the difference between refreshing for twenty minutes and coming back in an hour. For anything automated it matters more: A client that ignores Retry-After and retries immediately is actively making the situation worse, and it is the reason load shedding sometimes fails to relieve load at all. If you are writing a client, respect it, and add jitter so that every client you have deployed does not return at exactly the same instant.

What it means for search

This is the practical reason site operators should care about using 503 correctly. Search engines treat it as a signal to come back later and leave the page in the index. A page that returns 404 during maintenance, or redirects to a maintenance page with a 302, will eventually be treated as gone.

Google has been explicit that a few days of 503 is fine and treated as temporary, but that weeks of it will lead to pages being dropped. The correct pattern for planned downtime is a 503 with a Retry-After on every affected URL - Not a redirect, not a 200 page saying "we are down", which tells a crawler the page now legitimately contains those words.

503 versus 429

Both are refusals, and the distinction is about who is at fault.

A 503 is about the server: It cannot serve anyone right now, or at least not you, because of its own capacity.

A 429 is about you: The server is fine and you have exceeded a limit that applies specifically to your client, your key or your address.

If everyone is getting the error, it is a 503 situation. If only you are, it is a 429 situation, whatever number was actually returned.

What to do

As a visitor: Read the page. If it says maintenance, note the time and come back. If it is a queue, stay in it - A queue that shows a position is working. Do not refresh aggressively; during load shedding that can push you further back, and during maintenance it accomplishes nothing.

As an operator, three things. Always send Retry-After, because clients that cannot see an estimate will guess and guess badly. Make the 503 page cheap to serve - Static, no database, no application code - Because during load shedding it is the most requested page on your site. And make sure your health check endpoint does not itself return 503 during maintenance unless you want your load balancer to remove the server entirely.