Si tenés scripts, webhooks o agentes de IA que consultan GitLab.com sin autenticarse, el 19 de octubre vas a empezar a ver errores 429. GitLab redujo drásticamente el margen para el tráfico anónimo y ordenó el resto de los límites según el plan de cada cuenta, una respuesta directa al crecimiento de bots y agentes de codificación que golpean su API sin parar.
El rate limiting de GitLab.com es el mecanismo que controla cuántas requests por hora puede hacer un cliente a la API o al sitio antes de recibir un error HTTP 429. Desde el 19 de octubre de 2026, GitLab ata esos límites al plan de suscripción (Free, Premium, Ultimate) y castiga con solo 60 requests por hora a cualquier IP que no se autentique, sea un script, un bot o un agente de IA.
¿Por qué GitLab cambia los rate limits ahora?
Porque el tráfico de agentes de IA y automatizaciones está saturando la infraestructura de GitLab.com más rápido de lo previsto. Según el blog oficial de GitLab, la demanda está creciendo rápido y la compañía espera que la carga de la plataforma crezca varias veces este año.
GitLab no es el único caso: InfoWorld señala que "companies including Anthropic and GitHub have introduced similar rate limits" ante el mismo fenómeno, según reporta InfoWorld. El patrón es consistente en toda la industria: agentes de codificación, bots de scraping y herramientas de CI que consultan la API en bucle, muchas veces sin credenciales, generan picos de carga que antes no existían.
¿Cuáles son los nuevos límites de GitLab.com por plan?
Los límites autenticados escalan según el plan: 5.000 requests por hora en Free, 15.000 en Premium y 25.000 en Ultimate, mientras que cualquier request sin autenticar cae a 60 por hora por IP, sin importar el plan de la cuenta detrás.
| Tipo de tráfico | Free | Premium | Ultimate |
|---|---|---|---|
| Autenticado (por hora) | 5.000 | 15.000 | 25.000 |
| Burst por minuto | 100 | 1.250 | 2.000 |
| Anónimo (por IP/hora) | 60 | 60 | 60 |
El salto más brusco es el del tráfico anónimo: según detalla WorkOS, antes de este cambio ese tráfico podía llegar a 500 solicitudes por minuto, y ahora queda reducido a 60 por hora. Es una caída de más de dos órdenes de magnitud para cualquier cliente que no mande credenciales.
¿Cuándo entra en vigencia el cambio?
Para cuentas Free y tráfico sin autenticar, el cambio es definitivo desde el 19 de octubre de 2026, pero GitLab ya hizo dos simulacros previos. Hubo ventanas de prueba el 7 y el 14 de octubre, de 15:00 a 19:00 UTC, en las que los nuevos límites se activaron temporalmente y después se desactivaron, para que los equipos pudieran ver el impacto real sin quedar bloqueados de forma permanente.
- 7 y 14 de octubre: ventanas de preview de 4 horas (15:00-19:00 UTC) solo para Free y tráfico anónimo.
- 19 de octubre: los límites quedan activos de forma permanente para Free y no autenticados.
- Enero de 2027: Premium y Ultimate adoptan sus propios límites por plan.
Esto le da a los equipos pagos varios meses extra de margen, pero no es una excusa para posponer la auditoría: cualquier automatización que corra sin token, sin importar el plan de la cuenta, ya cae en el pool anónimo de 60/hora apenas arranque el 19 de octubre.
¿Qué pasa si mi script o agente de IA no está autenticado?
Cae automáticamente en el límite de 60 requests por hora por IP, aunque la cuenta detrás sea Ultimate, porque la facturación no viaja con la solicitud. GitLab identifica al cliente por la IP de origen cuando no hay token, personal access token, OAuth token o CI/CD job token en el header de autorización.
Esto genera una trampa frecuente en equipos que asumen que su plan los protege: un cron job, un dashboard interno o un agente de IA que llama a la API "porque siempre funcionó" puede estar compartiendo esa misma IP con otros servicios, agotando la cuota de 60 requests mucho antes de lo esperado.
¿Cómo sé si mi automatización va a verse afectada?
Hacé un inventario de todo lo que consulta GitLab.com de forma recurrente antes de que termine la semana del cambio. Los candidatos típicos son scripts cron, webhooks, dashboards de monitoreo, herramientas de scanning de repositorios y cualquier agente de codificación asistido por IA que itere sobre proyectos o merge requests.
- Revisá las credenciales de cada caller: confirmá si manda un personal access token, un OAuth token o un CI/CD job token en cada request, no solo en algunas.
- Detectá tokens compartidos: si varios workloads distintos usan el mismo token, un error 429 no te va a decir cuál de todos es el responsable.
- Medí la frecuencia real: un polling en loop ajustado, sin backoff, es el patrón que más rápido agota tanto el límite anónimo como el autenticado.
- Sumá los agentes de IA al inventario: muchas herramientas de code review o generación automática de merge requests hacen llamadas repetidas a la API que antes pasaban desapercibidas.
¿Cómo evito los 429 en la práctica?
La solución de fondo es autenticar cada request y dejar de depender del tráfico anónimo, que es el que recibe el recorte más agresivo. A partir de ahí, las prácticas estándar de manejo de rate limits hacen la diferencia entre una automatización estable y una que falla en producción.
- Autenticá siempre: cualquier request con token, OAuth o CI/CD job token sale del pool anónimo de 60/hora y pasa a la cuota de tu plan, que es ordenes de magnitud mayor.
- Usá un principal por workload: si cada bot o script tiene su propio token, un 429 te dice exactamente qué proceso hay que ajustar, en vez de obligarte a revisar todo.
- Mirá el header
RateLimit-Remaining: te dice cuánta cuota te queda en la ventana actual antes de que te corten. - Respetá
Retry-After: GitLab devuelve ese header en los 429; reintentar de inmediato solo empeora las cosas, mientras que el backoff exponencial recupera cuota más rápido. - Batch, cache y paginá: en vez de hacer polling constante, agrupá llamadas, cacheá respuestas que no cambian seguido y usá paginación eficiente para no quemar requests de más.
¿Qué son las cuentas de servicio y sirven para esto?
Son cuentas creadas específicamente para automatizaciones, disponibles desde GitLab 18.11, que escapan al límite anónimo de 60/hora y heredan la cuota del plan del grupo que las crea. A diferencia de un usuario humano, no consumen un asiento pago, lo que las hace la opción recomendada para bots y agentes de IA que necesitan identidad propia sin sumar costo de licencias.
En cuentas Free el límite es de 100 service accounts por grupo; en Premium y Ultimate no hay tope. Eso sí: crear múltiples tokens bajo la misma cuenta de servicio no multiplica la cuota, porque todos esos tokens siguen compartiendo el mismo bucket horario de requests.
¿Qué puede hacer un developer con esto hoy?
Lo primero es correr el inventario de automatizaciones mencionado arriba y migrar cualquier script o agente de IA que hoy pegue a GitLab.com sin token hacia una cuenta de servicio con su propio personal access token. Si administrás CI/CD, verificá que los pipelines usen el CI/CD job token en vez de hardcodear credenciales o, peor, dejar requests sin autenticar.
Si tu equipo corre agentes de codificación o herramientas de scraping de repositorios a gran escala, también vale la pena evaluar si conviene alojar una instancia self-managed de GitLab Community Edition o Enterprise Edition en infraestructura propia, donde vos controlás los límites de rate limiting en lugar de depender de los de GitLab.com. Para ese escenario, un servidor cloud con recursos dedicados —como los que ofrece Donweb Cloud— te da el control total sobre la configuración del servidor sin las restricciones de la plataforma SaaS.
Preguntas frecuentes
¿El cambio de rate limits afecta a instancias self-managed de GitLab?
No, estos límites aplican únicamente a GitLab.com, la plataforma SaaS alojada por GitLab Inc. Las instancias self-managed, ya sea GitLab CE o EE corriendo en tu propia infraestructura, definen sus propias reglas de rate limiting de forma independiente.
¿Cuánto tráfico anónimo permite GitLab.com después del 19 de octubre?
Apenas 60 requests por hora por dirección IP, sin importar el plan de la cuenta asociada. Es una caída drástica respecto del límite anterior, que según WorkOS llegaba a 500 solicitudes por minuto para tráfico sin autenticar.
¿Qué le pasa a mi cuenta Premium o Ultimate si no hago nada?
Nada hasta enero de 2027, cuando esos planes adoptan sus propios límites de 15.000 y 25.000 requests autenticadas por hora respectivamente. Pero si tus scripts no mandan credenciales, ya están limitados a 60/hora desde el 19 de octubre, independientemente del plan.
¿Cómo sé si una request está golpeando el límite anónimo o el autenticado?
Revisá si el header de autorización de la request incluye un personal access token, un OAuth token o un CI/CD job token. Si no incluye ninguno de los tres, GitLab la trata como anónima y la limita a 60/hora por IP sin importar qué cuenta esté detrás.
¿Las cuentas de servicio consumen un asiento de licencia?
No, las service accounts introducidas en GitLab 18.11 no cuentan como asientos pagos, a diferencia de los usuarios humanos. Por eso son la opción recomendada para identificar bots y agentes de IA sin sumar costo de licencia.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
