S3 request rate exceeded per-prefix limits (3,500 PUT / 5,500 GET per prefix per second).
S3 request rate exceeded per-prefix limits (3,500 PUT / 5,500 GET per prefix per second).
Shard object key prefixes and use exponential backoff; the AWS SDK does this automatically if you enable retries.
S3 access logs, CloudFront distribution logs, or the browser response headers (`x-amz-request-id`).
Amazon S3 — object storage, often fronting a static site or CDN.
The server is temporarily unable to handle the request — used for planned maintenance, overload, or rate limiting. Implies the server will recover.
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.
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.
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.