Retry-After Header

Retry-After is an HTTP response header that tells a client when it may safely try again. Its value is either a number of seconds or an HTTP date. Servers commonly send it with 429 Too Many Requests, 503 Service Unavailable, and some redirects.

Why it matters

Without guidance, clients guess, and guesses tend to be too aggressive. An explicit wait time lets a server in trouble shape the retry traffic coming back at it. Well-behaved crawlers, API clients, and monitors respect it.

Example

HTTP/1.1 503 Service Unavailable
Retry-After: 120

or with a date:

Retry-After: Thu, 08 Oct 2026 12:00:00 GMT

For planned maintenance, returning 503 with Retry-After tells search engines the outage is temporary, so they come back later instead of dropping pages. You can inspect headers on your own site with the HTTP header checker.

Common mistakes

• Sending it on a 200 or 404, where clients may ignore it.
• Setting a very short value during an outage, which invites a flood of retries.
• Clients that ignore it and keep their own faster retry loop.
• Using a date in the wrong format. It must be an HTTP-date, not ISO 8601.

Related

• Rate limiting
• Retry with backoff
• Maintenance window
• Load shedding

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.