429 Too Many Requests significa que el servidor te está limitando: el cliente ha enviado en un periodo más peticiones de las que el servidor permite y debería esperar antes de volver a intentarlo. No hay nada roto, y repetir la petición de inmediato lo empeora. Un servidor bien configurado indica cuánto esperar en una cabecera Retry-After; un cliente bien hecho espera al menos ese tiempo y, si no la hay, va espaciando los reintentos con esperas cada vez más largas. Cuando un monitor recibe un 429, la solución habitual es eximir al monitor del límite o comprobar un endpoint que no lo tenga.
Cómo funciona el rate limiting
El RFC 6585 define el 429, pero deja las reglas en manos de cada servidor. Un límite tiene tres partes:
A quién se cuenta: una dirección IP, una clave de API, una cuenta de usuario o una combinación. Los límites por IP cuentan juntos a todos los que están detrás de la misma dirección.
Qué se cuenta: todas las peticiones o solo algunas, como los inicios de sesión, las búsquedas o un endpoint de API costoso, a menudo con un límite más estricto.
Cómo se cuenta el tiempo: una ventana fija se reinicia cada minuto; una ventana deslizante mira los últimos 60 segundos; un token bucket se rellena a un ritmo constante y permite ráfagas cortas hasta su capacidad.
La respuesta suele indicarte en qué punto estás:
HTTP/2 429
retry-after: 30
x-ratelimit-limit: 100
x-ratelimit-remaining: 0
x-ratelimit-reset: 1793091600
Retry-After es estándar y contiene un número de segundos o una fecha HTTP. Las cabeceras X-RateLimit-* son una convención habitual, no un estándar, y su significado varía: reset puede ser un tiempo Unix o un número de segundos, así que consulta la documentación de la API. Un borrador del IETF define los campos estándar RateLimit y RateLimit-Policy, que algunas API ya han empezado a enviar.
De dónde vienen los 429
API de terceros a las que llamas, como servicios de pago, email, mapas o chat, que limitan cada clave o cuenta.
Tu propio API gateway o framework, mediante middleware de rate limiting.
Tu servidor web. El limit_req de nginx responde 503 por defecto; configura limit_req_status 429 para que los clientes sepan que deben ir más despacio en lugar de suponer una caída.
CDN y WAF, mediante reglas de rate limiting. Según la regla, la respuesta es un 429, un 403 o una página de verificación.
La protección de inicios de sesión y formularios de un CMS o un plugin de seguridad, que limita los intentos por dirección.
Cómo gestionar un 429 como cliente
Respeta Retry-After. Espera al menos lo que indique. Reintentar antes suele traer otro 429 y puede alargar un bloqueo.
Aplica backoff exponencial, con jitter. Sin Retry-After, espera más tras cada fallo, por ejemplo 1, 2, 4 y 8 segundos, más una parte aleatoria, para que muchos clientes no reintenten en el mismo momento.
Limita los reintentos. Tras unos cuantos intentos, desiste y notifica el error, o pon el trabajo en una cola para más tarde.
Envía menos peticiones. Guarda las respuestas en caché, usa endpoints por lotes, pide páginas más grandes y usa webhooks en lugar de polling cuando la API los ofrezca.
Reparte las tareas programadas. Los cron jobs que arrancan todos a la hora en punto chocan juntos con los límites; desplázalos unos minutos. La guía de expresiones cron explica cómo.
async function fetchWithBackoff(url, options = {}, attempts = 5) {
for (let attempt = 0; attempt < attempts; attempt++) {
const response = await fetch(url, options);
if (response.status !== 429) return response;
const retryAfter = Number(response.headers.get(‘retry-after’));
const wait = retryAfter > 0 ? retryAfter * 1000 : 2 ** attempt * 1000 + Math.random() * 1000;
await new Promise((resolve) => setTimeout(resolve, wait));
}
throw new Error(‘Still rate limited after ‘ + attempts + ‘ attempts’);
}
Este esbozo solo lee Retry-After como segundos; el código de producción también debería aceptar el formato de fecha.
Cómo poner límites de peticiones en tu propio sitio
Responde 429, no 503 ni 403. Un 503 parece una caída y un 403 un rechazo permanente; un 429 dice a los clientes y a las herramientas de monitorización exactamente qué ha pasado.
Envía Retry-After, para que los clientes no tengan que adivinar.
Limita por clave o por cuenta siempre que puedas. Los límites por IP castigan a oficinas, colegios y redes móviles, donde mucha gente comparte una dirección.
Permite ráfagas. Una carga de página puede lanzar decenas de peticiones a la vez; un token bucket con margen para una ráfaga evita bloquear a los visitantes normales.
Exime a tu monitorización, o dale su propio endpoint de health check sin límite.
# nginx: 10 requests a second per address, bursts of 20, answered with 429
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
}
}
Por qué un monitor de uptime puede recibir un 429
Una comprobación por minuto parece inofensiva, pero se acumula de formas fáciles de pasar por alto:
Varios monitores en un mismo host. Diez monitores sobre la misma API, cada uno comprobando cada minuto, son diez peticiones por minuto del mismo cliente, más las comprobaciones de confirmación cuando algo falla.
Límites estrictos en la ruta comprobada. Las páginas de inicio de sesión, la búsqueda y los endpoints de formularios suelen permitir solo unas pocas peticiones por minuto y dirección.
Direcciones compartidas. Las comprobaciones de un servicio de monitorización salen de unas pocas direcciones conocidas. Un límite por IP cuenta juntas todas las comprobaciones desde esa dirección, incluidas las de otros usuarios sobre el mismo sitio o API públicos.
Una regla contra bots que limita peticiones. Algunos firewalls cuentan aparte a los clientes automatizados y los limitan más que a los navegadores.
Qué hacer, por orden: eximir al monitor del límite por sus direcciones IP, monitorizar un endpoint de salud sin límite, comprobar con menos frecuencia o agrupar los monitores que atacan la misma API. No aceptes el 429 como activo en todos los casos, porque te conviene saber si un límite empieza a bloquear a tus usuarios reales. Los códigos de estado HTTP en la monitorización explica qué códigos tratar como fallos, y la checklist de monitorización de APIs, qué más vigilar en una API.
Los 429 y Uptimecheck
En la monitorización de uptime y la monitorización de APIs de Uptimecheck, un 429 queda fuera de los estados esperados por defecto (de 200 a 399), así que cuenta como caída cuando lo confirma una segunda comprobación. Cuando el servidor responde con un 429 sin más, la incidencia indica que nuestras comprobaciones están siendo limitadas, cita el valor de Retry-After si el servidor lo envió y sugiere eximir las peticiones cuyo user agent contenga “Uptimecheck”, comprobar con menos frecuencia o usar un endpoint sin ese límite. Las comprobaciones se hacen desde Estocolmo (Suecia); cómo permitir Uptimecheck en un firewall enumera las direcciones que debes eximir, con reglas para Cloudflare, incluidas sus reglas de rate limiting, y para nginx. Tú eliges el intervalo de cada monitor, desde cada minuto hasta cada hora.
Uptimecheck sigue las mismas reglas cuando envía tus alertas. Si Slack, Microsoft Teams, Discord o PagerDuty responden 429, la alerta se reintenta tras 30 segundos, 2 minutos, 10 minutos y 30 minutos, y nunca antes de lo que pida el Retry-After del servicio, hasta un máximo de una hora. Consulta por qué pueden no llegar las alertas para saber qué ocurre cuando un canal sigue fallando.
Distingue un límite de peticiones de una caída. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.