GitLab.com endurece su API: los rate limits ahora dependerán del plan
A partir del 19 de octubre de 2026, GitLab.com dejará de aplicar una política uniforme de rate limits en su API y pasará a diferenciar las cuotas según el plan contratado: Free, Premium y Ultimate tendrán cada una sus propios topes por usuario y por grupo de nivel superior. Las cuentas Free y las peticiones sin autenticar serán las primeras en sentir el cambio; los usuarios de Premium y Ultimate entrarán al nuevo régimen en enero de 2027, según anunció GitLab en un comunicado publicado el 17 de septiembre.
La decisión llega en un momento de fuerte crecimiento del consumo automatizado. GitLab reconoce que «la demanda está creciendo rápidamente» y que la carga de la plataforma se multiplicará varias veces este año, en parte empujada por la automatización tradicional y, sobre todo, por los agentes de IA que ya operan sobre el repositorio. Bajo esa presión, mantener una única cuota global deja de ser viable: un cliente desbocado puede degradar la experiencia del resto.
Qué cambia exactamente
Las nuevas reglas se aplican por usuario y por grupo top-level, no por IP global como ocurría hasta ahora. El comunicado destaca tres puntos centrales:
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad- Free y sin autenticar entran primero. El 19 de octubre de 2026 se aplican los nuevos topes para cuentas Free y para todas las peticiones sin credenciales. Las cuentas de pago no notarán nada hasta enero de 2027.
- Sin token, límite de 60 peticiones por hora por IP. Cualquier request que llegue a GitLab.com sin un token válido —personal access token, OAuth token o CI/CD job token— quedará limitada a esa cuota anónima, independientemente de que el repositorio sea público o pertenezca a una cuenta de pago.
- Topes por plan, más generosos en Premium y Ultimate. GitLab no publicó cifras exactas en el blog y remitió a la documentación de rate limits para los valores definitivos, pero asegura que el límite Free y el allowance anónimo «se alinean con la norma del sector», mientras que Premium y Ultimate se sitúan en niveles que otras plataformas reservan a sus tiers enterprise.
Ventanas de prueba antes del cambio
GitLab programó dos preview windows — los ingenieros las llaman brownouts — para que los equipos midan el impacto antes de que los nuevos límites sean definitivos. Serán el 7 de octubre y el 14 de octubre, entre las 15:00 y las 19:00 UTC. Durante esas cuatro horas GitLab activará los nuevos topes para tráfico Free y anónimo y luego volverá al régimen actual; el resto del servicio no se ve alterado. El objetivo, según la compañía, es que cada equipo vea cómo se comportan sus propias cargas de trabajo bajo los nuevos límites antes de que entren en vigor.
Si tu automatización es de pago (Premium o Ultimate), esas ventanas no te afectarán: tus límites solo cambian en enero de 2027. Lo que sí debes probar son las integraciones de tus proyectos públicos y cualquier script que hoy corra sin credenciales.
Qué hacer si tu integración se queda corta
El propio comunicado propone un plan de acción en tres pasos para los equipos que descubran que están cerca del límite:
- Autenticar las peticiones. Es el cambio más rentable. Pasar de un request anónimo a uno firmado con un personal access token, un OAuth token o el CI/CD job token mueve la llamada del cupo de 60/hora al límite de tu plan, que es «mucho mayor», según GitLab.
- Revisar cómo llamas a la API. Batch, caché y paginación ahorran presupuesto; en cambio, polling en loop cerrado lo quema. Si una vez que lo implementes sigues topando, el servidor responde con un HTTP 429 y un header Retry-After indicando cuánto esperar. Un cliente que lea sus propios headers se autorregula; un backoff exponencial recupera más rápido que un retry inmediato.
- Considerar upgrade. Las cuentas Premium y Ultimate reciben topes más altos por usuario y por grupo top-level. Para cargas puntuales, GitLab también anunció que está preparando una opción de comprar capacidad adicional por encima del plan, con detalles previstos para finales de este año.
Además, GitLab adelantó que construye una vista dentro del producto, con lanzamiento previsto para finales de 2026, que mostrará el consumo frente a los límites del plan. Hasta entonces, la señal más rápida es el header RateLimit-Remaining en cada respuesta de la API.
Preguntas que te van a llegar esta semana
El comunicado incluye un bloque de FAQ que conviene tener a mano porque probablemente circulará en canales internos y de soporte:
- ¿Cómo sé si me afecta? Compara tu minuto más cargado contra los topes publicados para tu plan. Si no estás cerca, no lo notarás.
- Mi proyecto público recibe mucho tráfico anónimo. Tres salidas: que la automatización se autentique, hacer el repo privado si el tráfico no es el esperado, o subir a Premium o Ultimate.
- ¿Y si soy miembro de varios grupos top-level? Tu límite de usuario será el del tier más alto disponible. Si perteneces a un grupo Ultimate, tendrás el límite Ultimate.
- ¿Qué pasa si una integración legítima no puede autenticarse? GitLab abrió el canal [email protected] para casos como badges de estado públicos. Si te preocupa que un bot propio quede excluido, escríbeles.
- ¿Afecta a GitLab Self-Managed o Dedicated? No. El cambio aplica solo a GitLab.com.
Qué significa esto para tu startup
Si tu startup corre pipelines, bots de code review, scrapers de issues o agentes de IA contra repos en GitLab.com, octubre es el mes para auditar tu tráfico. Tres recomendaciones operativas inmediatas:
- Inventario de llamadas anónimas. Antes del 7 de octubre, mapea qué integraciones pegan hoy contra GitLab.com sin token. Cualquiera que supere 60 req/h por IP se va a romper el día 19. La mayoría de CI runners ya usan CI/CD job tokens; el riesgo está en scripts legacy, webhooks mal configurados o herramientas de terceros que dejaron de mantenerse.
- Negociar la cuota con tu cuenta. Si dependes de GitLab.com para repos públicos con integraciones externas — muy típico en OSS y en integraciones con partners — habla con tu account team antes de enero. El nuevo mecanismo de compra de capacidad adicional aún no tiene precio público, pero los early movers suelen conseguir mejores condiciones.
- Diseñar clientes que lean headers. Los headers RateLimit-Remaining y Retry-After son ya la fuente de verdad; invertir unas horas en que tu SDK los respete te protege de cualquier ajuste futuro, no solo de este.
En el agregado, el movimiento confirma una tendencia: las plataformas de DevOps están dejando de tratar la API como un recurso ilimitado y empiezan a monetizar el throughput, igual que ya hacen AWS, OpenAI o Stripe. Los equipos que internalicen el coste por request hoy van a tener menos sorpresas cuando llegue el siguiente ajuste.
Fuentes
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
