---
title: "503 Service Unavailable"
canonical: "https://lemwatch.com/http-status-codes/503"
category: "server-error"
last_verified: "2026-08-11"
source: "https://lemwatch.com"
---

# HTTP 503 Service Unavailable

**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 it means

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

- 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
- For overload: scale the bottleneck — more worker processes, larger DB connection pool, caching layer, or auto-scaling triggered by CPU/queue depth
- For rate limiting: confirm the client is genuinely abusive before tightening; tune limits per-route rather than globally
- For application pool recycling: stagger recycles so not all workers restart simultaneously
- 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)
- 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.

## Monitoring tip

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.

**Related:** [500](https://lemwatch.com/http-status-codes/500.md), [502](https://lemwatch.com/http-status-codes/502.md), [504](https://lemwatch.com/http-status-codes/504.md), [429](https://lemwatch.com/http-status-codes/429.md)

_Canonical HTML page: https://lemwatch.com/http-status-codes/503_