GitLab.com rate limits will align with your subscription from October 19, and anonymous requests fall to 60 per hour per IP

GitLab published a blog post on 17 September saying it will change how rate limits work on GitLab.com. Starting 19 October 2026, limits on Free accounts and unauthenticated requests will align with the subscription tier of the caller. Premium and Ultimate limits move to the same model in January 2027.

What changes on 19 October

Anonymous requests, meaning any HTTP call to GitLab.com with no credentials attached, get 60 requests per hour per IP address. GitLab says an authenticated request is instead governed by the plan of the account it belongs to. The per-plan numbers are published in GitLab's rate limits documentation.

Two preview windows come first, on 7 October and 14 October, from 15:00 to 19:00 UTC. GitLab calls these brownouts: it switches the new limits on for four hours and then switches them back off, so a team can see how its own traffic behaves before the change is permanent. Signed-in Premium and Ultimate traffic is not affected during the previews, because those limits only change in January.

What GitLab is telling callers to do

When a caller crosses a limit, GitLab returns 429 Too Many Requests with a Retry-After header, and Sam Wiskow's post says a client that reads its own response headers "mostly fixes itself" if it backs off exponentially. The RateLimit-Remaining header on any successful response tells a script how much of its current window it has left. GitLab says a product view of usage against plan limits is scheduled for later this year.

For a public project that receives anonymous traffic, GitLab lists three options: ask the automation that calls it to authenticate so it moves onto its own plan's limits, make the project private if the traffic is not from the intended audience, or upgrade to Premium or Ultimate for higher ceilings. The post also mentions that a paid overage capacity above the standard plan limits is being worked on, with details due later in 2026.

The reader who has to act, and by when

Almost every anonymous caller a team owns is a scripted one, and 60 requests per hour is easy to blow through without noticing. That is the population this change touches most: a CI job in another platform that clones a public GitLab repository over HTTPS with no token, a status badge that polls a pipeline endpoint, a data script that walks the API for release metadata, an agent framework that reads a public issue tracker. Every one of those can be switched from anonymous onto a plan's limits by adding a personal access token, an OAuth token, or a CI/CD job token to its request, which GitLab describes as usually a small change.

The window to test is short. The 7 October preview is the moment to run a normal day's workload against the new limits and watch for 429s. GitLab Self-Managed and GitLab Dedicated limits stay with the operator and are unaffected.

Source

Primary source: Rate limits on GitLab.com are changing, by Sam Wiskow on GitLab's blog, 17 September 2026. Per-plan numbers: Rate limits documentation.