Retry-After
Uso
La cabecera Retry-After aparece en las respuestas en las que el servidor necesita que el cliente espere antes de reintentar. Esta cabecera suele acompañar a tres códigos de estado:
La cabecera admite dos formatos: un retardo en segundos (delta-seconds) o una HTTP-date absoluta. Cuando se usan segundos, el valor es un entero no negativo que representa el número de segundos de espera. Cuando se usa una HTTP-date, el valor sigue el formato IMF-fixdate.
Los clientes y rastreadores que se comportan correctamente respetan esta cabecera para no saturar un servidor que se está recuperando.
Nota
Los rastreadores de los motores de búsqueda interpretan Retry-After en las respuestas 503 como una señal para volver a visitar la URL más adelante, en lugar de eliminar la página del índice. Tanto Googlebot como Bingbot respetan esta cabecera para programar nuevas visitas. Durante un mantenimiento planificado, devolver 503 Service Unavailable con Retry-After preserva la indexabilidad. Sin esta cabecera, una interrupción prolongada corre el riesgo de provocar la desindexación.
Delta-seconds
Un entero no negativo que especifica el número de segundos que el cliente debe esperar antes de reintentar la solicitud.
Retry-After: 120HTTP-date
Una fecha y hora absolutas en formato IMF-fixdate a partir de las cuales el cliente puede reintentar libremente. La fecha usa GMT y sigue el formato Day, DD Mon YYYY HH:MM:SS GMT.
Retry-After: Sat, 31 Oct 2026 18:00:00 GMTEjemplo
Un servidor que responde con 503 durante una ventana de mantenimiento indica al cliente que espere 3600 segundos (una hora) antes de reintentar.
HTTP/1.1 503 Service Unavailable
Retry-After: 3600Un limitador de velocidad de una API que responde con 429 proporciona la fecha absoluta en la que se restablece el límite. El cliente detiene las solicitudes hasta el momento indicado.
HTTP/1.1 429 Too Many Requests
Retry-After: Sat, 31 Oct 2026 12:30:00 GMTUna redirección programada con 301 incluye un retardo para evitar tormentas de reintentos inmediatos desde varios clientes.
HTTP/1.1 301 Moved Permanently
Location: https://new.example.re/resource
Retry-After: 60Nota
Los limitadores de velocidad de las API suelen combinar Retry-After con las cabeceras RateLimit-Limit. La cabecera RateLimit-Remaining muestra cuántas solicitudes quedan en la ventana actual, mientras que Retry-After indica a los clientes exactamente cuándo reanudar tras una respuesta 429. Las API bien diseñadas incluyen ambas para que los clientes se retiren de forma ordenada en lugar de machacar un endpoint con límite de velocidad.