On 17 September GitLab published a short, calm post explaining that rate limits on GitLab.com are changing. Free accounts and unauthenticated requests move on 19 October 2026; Premium and Ultimate follow in January 2027. The tone is reassuring, and for most individual developers it is accurate: almost nobody will notice.
That is exactly why it is worth paying attention. The interesting part of the announcement is not the numbers, it is the model. GitLab.com is moving from “the API is a utility that is roughly always there” to “API access is a budget attached to an identity”. Frame it that way and a question surfaces that most engineering teams genuinely cannot answer: whose budget is your automation spending?
TL;DR
- From 19 October 2026, GitLab.com rate limits align with subscription tier: 5,000 requests per hour on Free, 15,000 on Premium, 25,000 on Ultimate, per user and per top-level group. The paid tiers activate in January 2027.
- Unauthenticated requests get 60 per hour per IP address, including automation running against a paid account without credentials.
- Burst limits (100, 1,250 and 2,000 requests per minute) are ceilings for spikes, not sustainable rates: holding the burst rate exhausts the hourly allowance in roughly 50 minutes on Free and about 12 minutes on the paid tiers.
- The real exposure is identity, not volume: shared bot accounts become a throttling chokepoint, and AI coding agents on a developer’s personal access token quietly spend that developer’s allowance.
- GitLab is running two preview windows (“brownouts”) on 7 and 14 October, 15:00 to 19:00 UTC. Treat them as a free, scheduled load test.
What is actually changing
Today GitLab.com applies broadly uniform limits. From 19 October, authenticated traffic is governed by the plan attached to the identity making the request, measured per user and per top-level group: 5,000 requests per hour on Free, 15,000 on Premium and 25,000 on Ultimate, with unauthenticated traffic capped at 60 per hour per IP address on every tier. Each plan also carries a burst limit measured per minute: 100 on Free, 1,250 on Premium, 2,000 on Ultimate. The limits cover API requests, web requests and authenticated Git over HTTPS.
Read the two sets of numbers together and something useful falls out. The hourly limit takes precedence, so the per-minute figure is a spike allowance, not a throughput target. GitLab spells out the arithmetic: hold the per-minute ceiling and you hit the hourly wall in about 50 minutes on Free, 12 minutes on Premium and 12.5 minutes on Ultimate. Upgrading raises the ceiling considerably, but it also gives a badly behaved client a faster route to exhausting the hour. A tight polling loop on Ultimate is not safer than one on Free. It just fails later, on a more expensive plan.
The anonymous allowance is where teams will get caught
Sixty requests per hour per IP address is a small number, and the one most likely to surprise people. GitLab is explicit that the cap applies “no matter where they come from, including automation running against a paid account without credentials”. Paying for Ultimate does not help a script that never authenticates.
In practice, unauthenticated callers are everywhere in a typical delivery estate, and almost none of them were designed. Documentation link checkers. Status dashboards pulling pipeline state. A curl in a Makefile fetching a raw file from a public repo. Internal tooling reading public project metadata because nobody wanted to provision a token for something so trivial. Add a shared office or VPN egress IP and all of them compete for the same sixty requests, alongside every developer’s browser. None of it is unreasonable traffic. It is simply anonymous, and anonymous is no longer a supported mode of operation at any meaningful volume.
Whose token is that?
Here is the governance question underneath the announcement. Limits attach to identities, so your throttling behaviour is decided by how your automation authenticates. Most organisations have drifted into one of two patterns, and both have a defect.
The first is the shared bot account. Every pipeline, integration and internal tool authenticates as ci-bot, which holds a single hourly budget for the whole organisation. Tidy from an access-control perspective, and a perfect chokepoint: one runaway nightly job throttles every other automated consumer at once, and the failure presents as an unrelated integration mysteriously returning 429 at 02:40.
The second is worse and more common: automation authenticates as whichever human happened to generate a personal access token when the integration was built. That person’s budget is now shared with a machine, and they may have left the company. In 2026 there is a hungrier participant in the arrangement, because AI coding agents are heavy, bursty API consumers. An agent asked to survey a large repository, walk merge request history or reconcile issues across projects can make hundreds of calls in a couple of minutes, spending the allowance of whoever owns the credential it was handed. The developer who sees the resulting 429 in their editor will have no idea why.
The fix is boring and worth doing: an inventory of every automated caller, what it authenticates as, how many requests it makes at peak, and whether that identity is a human. Use CI/CD job tokens for pipeline work, dedicated service accounts for integrations, and keep agent workloads on credentials separate from the humans they assist. Separating human and machine budgets is the single change that turns rate limiting from an outage into a line on a dashboard. It is the kind of unglamorous audit our DevOps and integrations work usually starts with, and it reliably surfaces integrations nobody remembered owning.
Do not trust the headers completely
GitLab returns RateLimit-Limit, RateLimit-Remaining and, on throttled responses, Retry-After and RateLimit-ResetTime. Instrumenting RateLimit-Remaining now, and alerting when any caller routinely burns past about 70 per cent of its window, tells you precisely how exposed you are before the deadline.
There is a caveat in the documentation that deserves more attention than it will get. Rate limiting responses for the Projects, Groups and Users APIs do not include the informational headers, and some other limits are not reflected either, so you can receive a 429 even when your previous response showed remaining quota. A throttle controller that gates outbound calls on the last observed RateLimit-Remaining value will be confidently wrong on exactly the endpoints that get enumerated in bulk. Treat the 429 as authoritative and the headers as advisory.
Two free load tests, on 7 and 14 October
GitLab is switching the new limits on briefly on 7 and 14 October, 15:00 to 19:00 UTC, then switching them off again. For teams in Dublin that is 16:00 to 20:00, and 17:00 to 21:00 in central Europe, so it lands inside the working day on both sides.
A vendor telling you in advance exactly when it will apply a breaking constraint to your production traffic is unusually generous, and the correct response is to plan for it rather than wait it out. Run the windows as a scheduled game day: watch your pipelines, log every 429 with the calling identity attached, and check whether anything retries in a tight loop instead of backing off. Four hours of real failure data on a date you chose beats any spreadsheet estimate of your busiest minute.
What to do before 19 October
- Inventory your callers and the identity each one authenticates as. Anything anonymous goes on the fix list first.
- Authenticate everything. A job token, OAuth token or PAT moves a caller off the 60 per hour anonymous allowance.
- Split human and machine budgets. Agents and integrations should not spend a named developer’s allowance.
- Replace polling with webhooks. The largest single reduction available to most teams, and it improves latency as a side effect.
- Cache, batch and paginate. Refetching project metadata that changes weekly is pure waste under a metered model.
- Back off with jitter. Honour
Retry-Afterand add jitter, so your fleet does not synchronise its retries into a second spike.
This is not really a GitLab story
GitLab is not doing anything unusual, and the limits themselves are reasonable. The direction is what matters. Platform APIs were provisioned for human-paced usage with some automation attached, and that assumption broke the moment agents became routine consumers. Every major platform is now working out how to meter identity rather than trust volume. Expect more of these announcements, with shorter notice.
The architectural implication is straightforward: treat every external API as a metered dependency. A named identity per caller, a known request budget, caching by default, events instead of polling, graceful degradation when the budget is gone, and observability that tells you which identity spent what. Agent workloads built without that scaffolding carry a cost and reliability problem that only becomes visible under load.
If you build automation or AI agents against platform APIs and cannot answer the “whose token is that?” question, that is this month’s work. Talk to us about auditing your integrations, separating machine identities from human ones, and designing agent workloads that behave when the budget runs out.
📷 Photo by Thomas Kelley on Unsplash
