Server Error

HTTP 503 Service Unavailable

The server is temporarily unable to handle the request — used for planned maintenance, overload, or rate limiting. Implies the server will recover.

Check a URL for HTTP 503

Paste any URL to see whether it currently returns 503. Runs a live HTTP probe and follows redirects.

TL;DR

A 503 means "the server is up but isn't handling requests right now — try again later." It is the correct status code for planned maintenance and overload. Always pair it with a Retry-After header so Googlebot and other clients know when to retry. Returning 503 without Retry-After is a missed opportunity that costs you crawl budget.

What does HTTP 503 mean?

HTTP 503 Service Unavailable is the "we're temporarily down, please try again later" status code. Unlike 500 (something crashed) or 502 (the upstream is unreachable), 503 is deliberately a soft signal: the server is up, but it has chosen not to serve this request right now. The expected use cases are planned maintenance, overload protection, rate limiting, and circuit breakers. Critically, a well-behaved 503 includes a Retry-After header telling clients (and search engine crawlers) when to come back — and Google specifically respects this for maintenance windows.

Common Causes

•Planned maintenance window (the canonical correct use)
•Application or web server overloaded — too many concurrent requests
•Rate limiting: client exceeded request quota
•Database connection pool exhausted under load
•Application pool recycling (IIS) or worker reload
•Autoscaling event in progress — new instances spinning up
•Circuit breaker tripped: downstream dependency failing, fail fast instead of cascading
•CDN shedding load during a traffic spike to protect the origin

How to Fix It

1.For planned maintenance: serve 503 with a Retry-After header set to the expected end of the window — Googlebot will respect it and won't deindex
2.For overload: scale the bottleneck — more worker processes, larger DB connection pool, caching layer, or auto-scaling triggered by CPU/queue depth
3.For rate limiting: confirm the client is genuinely abusive before tightening; tune limits per-route rather than globally
4.For application pool recycling: stagger recycles so not all workers restart simultaneously
5.Set up a static maintenance page returned with 503 + Retry-After, not 200 — never serve a "maintenance" page with 200 OK (Google may index it as your real homepage)
6.Add observability: track 503 rate per route to spot bottlenecks before they become outages

SEO Impact

When done correctly, almost no SEO impact. Google explicitly honours 503 + Retry-After for maintenance up to a few hours — pages stay indexed, crawl rate is preserved. When done wrong, severe: 503s without Retry-After are treated like generic server errors; 503s lasting more than a day or two cause deindexing; serving a maintenance page with 200 OK can pollute your index with duplicate "we'll be right back" pages. The correct pattern is always 503 + Retry-After + a useful HTML body.

Monitor HTTP 503 with LemWatch

LemWatch can be told about your maintenance windows so we don't fire false-positive alerts for an expected 503. We also detect when a Retry-After is missing — a frequent oversight that costs you Google's "this is just maintenance" goodwill.

History & Context

HTTP 503 was defined in HTTP/1.0 (RFC 1945, 1996) and reinforced in HTTP/1.1 with explicit guidance to include a Retry-After header. Google publicly documented in 2011 that Googlebot honours 503 + Retry-After for maintenance: as long as the 503 lasts less than a few hours and the Retry-After is reasonable, the affected pages stay indexed and the crawl rate isn't penalised.

Real-World Examples

GitHub maintenance windows

When GitHub takes a service offline for maintenance, it returns 503 with a Retry-After header pointing to the expected end of the window. Googlebot, monitoring tools, and CI systems all see the signal and back off cleanly.

Cloudflare Under Attack Mode

When Cloudflare's Under Attack Mode is triggered or a rate limit fires, Cloudflare returns 503 to abusive clients while letting humans (after JS challenge) through. This is a textbook use of 503 as a protective overload signal.

Stripe API rate limiting

Stripe returns 503 with a Retry-After header when an integration exceeds the API rate limit. Well-written clients use the Retry-After value to back off cleanly; badly-written ones just retry immediately and stay 503'd.

Correct 503 response for a maintenance window

http

HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=utf-8
Retry-After: 3600
Cache-Control: no-store

<!doctype html>
<title>We'll be right back</title>
<h1>Scheduled maintenance</h1>
<p>Lemwatch is offline for ~1 hour while we ship an upgrade.
Expected back at 14:00 UTC.</p>

# Nginx config that returns this during maintenance:
# error_page 503 @maintenance;
# location @maintenance {
#     add_header Retry-After 3600 always;
#     return 503;
# }

Frequently Asked Questions about HTTP 503

What does HTTP 503 mean?

HTTP 503 Service Unavailable means the server is temporarily unable to handle the request. It implies the situation is short-term and recoverable — maintenance, overload, or rate limiting — as opposed to 500 (something crashed) or 404 (the resource doesn't exist).

How do I fix an HTTP 503 error?

It depends on the cause. For maintenance: wait for the window to end. For overload: scale the bottleneck (more workers, bigger DB pool, caching). For rate limiting: slow down the client, respect the Retry-After header, request a quota increase. Check the server's logs and load metrics to identify which case you're in.

Is 503 bad for SEO?

Done right, no. Google honours 503 with a Retry-After header for maintenance — pages stay indexed and crawl rate is preserved. Done wrong (no Retry-After, or 503s lasting days), yes — affected pages get deindexed and crawl rate drops sitewide.

What is the Retry-After header?

A response header that tells the client how long to wait before retrying the request. It can be a number of seconds (Retry-After: 3600 = 1 hour) or an HTTP date (Retry-After: Wed, 21 Oct 2024 07:28:00 GMT). Google, Bing, and well-written API clients all respect it.

What is the difference between 503 and 500?

500 Internal Server Error means "we crashed, we don't know why." 503 Service Unavailable means "we're intentionally not serving right now, come back later." 503 is a controlled response; 500 is an uncontrolled failure.

Should I return 503 for planned downtime?

Yes — always. Returning 200 with a "we'll be right back" page is one of the most common SEO mistakes: Google may index that page as your homepage, and you lose visibility on the real page until the next crawl. 503 + Retry-After is the correct pattern.

How long can a 503 last before Google deindexes the page?

Google publicly says up to about a day or two with a reasonable Retry-After is fine. Beyond that, affected pages start getting deindexed and crawl rate drops. For longer planned outages, communicate publicly and consider a holding page on a separate URL.

Why is my site returning 503 randomly?

Almost always overload: too many requests competing for too few worker processes, database connections, or memory. Check your server's load metrics during the 503 spikes — they'll usually correlate with traffic peaks, slow database queries, or insufficient autoscaling.