Updated October 13, 2026. GitLab.com has announced plan-based request limits, with Free and anonymous traffic scheduled for October 19 and Premium/Ultimate for January 2027. The important question for a CI/CD team is not whether a headline percentage looks dramatic. It is whether requests from the same user or IP will exceed the new sustained or burst limit. GitLab’s documentation still labels the new table “proposed,” so recheck it as rollout approaches.
What changes, and what is still active today?
These are GitLab.com limits. GitLab says Self-Managed and Dedicated installations use limits controlled by their operators, so this announcement does not set their quotas. As of this check, GitLab’s documentation lists current authenticated API traffic at 2,000 requests per minute per user and unauthenticated traffic at 500 per minute per IP. The plan-based limits below are announced for rollout, not yet in effect.
| Traffic | Announced sustained limit | Announced burst limit | Scheduled rollout |
|---|---|---|---|
| Free, authenticated | 5,000 per user per hour | 100 per user per minute | October 19, 2026 |
| Premium, authenticated | 15,000 per user per hour | 1,250 per user per minute | January 2027 |
| Ultimate, authenticated | 25,000 per user per hour | 2,000 per user per minute | January 2027 |
| Anonymous, all plans | 60 per IP per hour | No separate burst figure announced | October 19, 2026 |
The sustained hourly cap and per-minute burst cap are separate constraints. You can hit either one first. Multiplying today’s 2,000-per-minute ceiling by 60 and comparing that theoretical 120,000-per-hour burst maximum with a sustained hourly allowance produces a large percentage, but it does not show how much a typical pipeline’s usable capacity will fall. GitLab also says the new limits apply across API, web, and authenticated Git-over-HTTPS requests, with additional endpoint-specific limits remaining in force.
When a pipeline should investigate
Start with the identity and scope behind the traffic. The published allowance is per user for authenticated traffic and per IP for anonymous traffic; several jobs sharing one credential can therefore share that user’s allowance. A request made without credentials may consume the much smaller anonymous pool even if the project itself belongs to a paid group.
Estimate hourly demand before changing the plan:
requests per hour = concurrent jobs × requests per minute per job × 60 × active hours
For example, 15 jobs each polling once every 10 seconds for an hour would generate up to 5,400 calls if they all use the same authenticated user and every poll reaches a counted endpoint. That is above the announced Free sustained allowance of 5,000. This is a scenario calculation, not a measurement of your project; real call patterns, credentials, endpoint exclusions, and other traffic change the result.
A practical check before the rollout
- Inventory scheduled polling, repeated list/detail calls, and jobs that run concurrently. Record which token or user identity each job uses.
- Authenticate requests where appropriate. GitLab lists personal access tokens, OAuth tokens, and CI/CD job tokens as ways to receive the authenticated plan allowance. Confirm that the selected token is supported for the endpoint and has only the needed scope.
- Batch operations when supported, cache stable responses, and paginate instead of repeatedly downloading full collections.
- Handle
429 Too Many Requestsby waiting forRetry-After; use exponential backoff and inspectRateLimit-Remainingand related headers. Do not retry in a tight loop. - Check endpoint-specific limits separately. A request can encounter a narrower endpoint or IP limit before the overall plan cap.
GitLab announced preview windows on October 7 and October 14, 15:00–19:00 UTC, for Free and anonymous traffic. The first window has passed. The second corresponds to October 15, 00:00–04:00 Korea Standard Time. If you rely on affected traffic, use that window to observe actual responses and logs; do not infer impact from the headline alone.
What the evidence does—and does not—tell us
GitLab says almost all users are already within the new limits and expects ordinary signed-in work to remain unchanged. That is the vendor’s aggregate assessment, not a guarantee for a particular heavily automated account. The docs page currently marks the plan-based table as proposed while the company blog gives the rollout dates. Treat the blog as the announced schedule and the docs as the operational source for limits, then verify both near the change.
We reviewed GitLab’s published documentation and announcement and checked the arithmetic in the example above. We did not run a pipeline against the preview limits, inspect a customer’s usage headers, or test a GitLab project. This article is a planning guide, not a finding that a specific CI system will fail.
Sources
- GitLab.com rate limits — current limits, proposed plan limits, 429 handling, scope, and endpoint exceptions.
- GitLab: Rate limits on GitLab.com are changing — announced rollout and preview dates.
- GitLab REST API authentication — supported authentication methods and token guidance.
- GitLab REST API — API usage and response conventions.
FAQ
Does this apply to self-managed GitLab? No. GitLab says this announcement covers GitLab.com; self-managed and Dedicated limits are controlled separately.
Will a paid account protect an unauthenticated CI request? No. GitLab says requests without credentials use the anonymous allowance regardless of whether the automation is associated with a paid account.
Should every team upgrade? Not based on the headline. First identify authentication, shared request identities, sustained volume, bursts, and endpoint limits. GitLab says most users should not notice a change, but only your measured workload can establish whether that applies to you.
Image credits
- Photo by Sergei Starostin on Pexels