Rate limits on GitLab.com are changing
GitLab.com hosts millions of projects for teams of every size that need a platform they can rely on, and demand is climbing quickly. GitLab expects platform load to grow several times over this year, and predictable limits are what keep the platform fast for everyone, including the automation and agent workloads teams are building on it. To hold that as it scales, GitLab is updating how rate limits work, aligning them with subscription tier: Free accounts and unauthenticated requests go first on October 19, 2026, with Premium and Ultimate following in January 2027.
Under the change, limits align with subscription so that Free, Premium, and Ultimate plans each get their own limits, applied per user and per top-level group. Signing in gets you the full limit, since an authenticated request is governed by your subscription plan. A request that arrives with no credentials gets 60 requests per hour per IP address, and the per-plan limits are published in GitLab's rate limits documentation.
Before the rollout, there will be two preview windows for Free and unauthenticated traffic, on October 7 and October 14 from 15:00 to 19:00 UTC. Signed-in Premium and Ultimate requests are not affected because those limits do not change until January. Unauthenticated requests are capped no matter where they come from, including automation running against a paid account without credentials. A preview window — which GitLab engineers call a brownout — is a short, planned window where the new limits are switched on and then switched back off, with nothing else about the service changing. The point is to give users a real look at how their own workloads behave under the new limits weeks before they apply for good. On October 19, the new limits take effect.
GitLab set the limits by looking at how GitLab.com is actually used, and almost all users are already inside the new limits and won't notice any change. It also looked at what similar platforms allow: the Free limit and the anonymous allowance match the industry norm, while Premium and Ultimate are more generous, at levels other platforms reserve for their enterprise tiers or don't publish at all.
For users who find themselves nearing a limit, GitLab recommends authenticating requests — invoking a personal access token, an OAuth token, or the CI/CD job token moves a request off the anonymous 60 requests per hour and onto the plan's much higher limits. It also suggests examining how the API is called, since batching, caching, and pagination go a long way, and polling in a tight loop burns through an allowance fast. When a limit is crossed, the API returns an HTTP 429 with a Retry-After header indicating how long to wait, so a client that reads its own response headers mostly fixes itself, and backing off exponentially recovers faster than retrying immediately. Upgrading to Premium or Ultimate increases the available limits.