GitLab is rolling out stricter request caps for its hosted platform, targeting both API calls and Git over HTTPS. Starting October 19, free‑tier users and any unauthenticated traffic will be limited to 60 requests per hour per IP, while authenticated free users get 5,000 per hour, Premium 15,000, and Ultimate 25,000. Per‑minute bursts are also capped (100 / 1,250 / 2,000 respectively). The change is driven by a surge in AI‑generated automation that is flooding the service with traffic.
GitLab API Rate Limits by Subscription
- Unauthenticated traffic: 60 requests per hour, regardless of the project’s plan.
- Free tier (authenticated): 5,000 requests per hour, 100 per minute.
- Premium tier: 15,000 requests per hour, 1,250 per minute.
- Ultimate tier: 25,000 requests per hour, 2,000 per minute.
Free‑tier limits become permanent on October 19; Premium and Ultimate limits will be enforced beginning January 2027. GitLab will run two four‑hour test windows on October 7 and October 14 (08:00‑12:00 PT) where the new caps apply to free and unauthenticated traffic, giving teams a chance to surface breakages before the official start date.
Why AI‑Driven Automation Must Adjust
AI coding agents and other automated tools often issue large numbers of short‑lived API calls. Without proper authentication, those calls fall under the 60‑per‑hour anonymous bucket, which can quickly throttle even modest automation pipelines. The limits therefore force engineers to:
- Ensure every automated client presents a personal access token, OAuth token, or CI/CD job token.
- Implement caching or result‑reuse to avoid repeated fetches of static data.
- Batch operations where possible instead of issuing one request per item.
- Reduce or eliminate aggressive polling loops.
GitLab will return HTTP 429 with a Retry-After header when a client exceeds its allowance, allowing the client to back‑off automatically.
Operational and Security Considerations
From an operations standpoint, the new limits introduce a measurable quota that can be observed via the RateLimit-Remaining response header. Teams should instrument their CI/CD runners, bots, and monitoring dashboards to track this header and alert when usage approaches the threshold.
Security‑wise, the distinction between authenticated and unauthenticated traffic means that token management becomes a performance control as well as an access control mechanism. Projects that rely on shared or public endpoints must migrate to authenticated calls to avoid the low anonymous ceiling.
GitLab also plans to expose a usage‑vs‑limit UI later in the year and to sell additional request allowances on demand. Until that UI is available, the only real‑time visibility comes from response headers and the temporary test windows.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Practitioners should audit all automated GitLab interactions before October 19. Verify that every script, bot, or AI agent includes a valid token, and adjust request patterns to stay within the per‑hour and per‑minute caps. Use the test windows to surface any hidden throttling, and add logic to handle 429 responses gracefully. Finally, monitor the RateLimit-Remaining header in production to detect emerging capacity issues before they impact pipelines.
