503 Service Unavailable: what it means and how to fix it

A 503 Service Unavailable error means the server is temporarily unable to handle the request, almost always because it is overloaded or down for maintenance. Unlike a 404, it says the page still exists and should work again later. Fix an unplanned 503 by finding what exhausted the server. For planned downtime, return 503 on purpose with a Retry-After header.

The HTTP specification says the server "is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay" (RFC 9110, section 15.6.4). The server may also send Retry-After to suggest how long the client should wait.

The Retry-After header

Retry-After tells clients, crawlers included, when to come back. RFC 9110 allows two forms: an HTTP date or a number of seconds (RFC 9110, section 10.2.3).

HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html

<h1>Down for maintenance</h1>
<p>We'll be back within the hour.</p>

Retry-After: 3600 means one hour. The date form looks like Retry-After: Fri, 31 Dec 1999 23:59:59 GMT. Use seconds unless you have a fixed end time, because a date depends on both clocks agreeing.

Common causes of an unplanned 503

How to fix a 503

1. Check whether it is planned. A maintenance plugin, a deploy script or a host's maintenance switch may still be on. WordPress answers with a 503 and Retry-After: 600 while a .maintenance file sits in the site root during updates (wp_maintenance). It treats maintenance as over 10 minutes after the update started (wp_is_maintenance_mode), and deleting the file ends it at once.
2. Measure the load. Compare the start of the errors with request volume. If a single client or bot produces a large share of requests, rate-limit or block it at the CDN or firewall.
3. Find the bottleneck. Look for exhausted workers, a saturated database connection pool or a slow external API. Add capacity, raise the worker count if memory allows, or cache the expensive pages.
4. Look for crashes. Out-of-memory kills and crash loops make the server unavailable while processes restart.
5. Shed load gracefully. If you can't add capacity right away, return 503 with Retry-After for the expensive routes and keep the cheap ones up. That is better than letting every request time out.

Slow pages hold workers for longer, so speed and capacity are linked. The Core Web Vitals checker shows how fast a page loads for real visitors, which helps you spot the heavy pages.

Planned maintenance done right

For planned downtime, 503 is the correct status. A maintenance page served with 200 tells search engines your "back soon" text is the real content of every URL. A 404 tells them the pages are gone.

Google's guidance for disabling a site for one or two days is to "return an informational error page with a 503 HTTP response status code instead of all content" (Google Search Central). It adds limits:

• Keep it short. Google calls this "an extreme measure that should only be taken for a very short period of time (a few days at most)."
• Don't send 503 for robots.txt. Google says this "blocks all crawling."
• Expect frozen snippets. While pages return 503, Google can't refresh titles, descriptions or structured data.
• For longer closures, use a 200 placeholder. Google recommends an indexable home page explaining the situation instead of a long-running 503.

A minimal nginx setup that serves maintenance as a real 503:

location / {
    if (-f /var/www/maintenance.on) {
        return 503;
    }
    proxy_pass http://app;
}

error_page 503 /maintenance.html;
location = /maintenance.html {
    root /var/www/static;
    add_header Retry-After 3600 always;
    internal;
}

Touch /var/www/maintenance.on to switch maintenance on and delete it to switch it off. Exclude /robots.txt from the rule so it keeps returning 200.

How Google treats 503

Google groups 503 with the other server errors. "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling", and content from 5xx responses is ignored. Indexed URLs are kept for a while but "eventually dropped", and URLs that persistently return a server error are removed (Google Search Central). Once the server returns 2xx again, Google raises the crawl rate gradually.

Google's crawl-rate guidance gives a rough clock. It allows returning 500, 503 or 429 to slow Googlebot "for a short period of time". It also warns that "if Googlebot observes these status codes on the same URL for multiple days, the URL may be dropped from Google's index" (Google Search Central). Hours of 503 are safe; days start to cost you.

After the site is back, check that each version of the homepage ends in a 200 with the redirect checker, which shows every hop and the final status code.