GitLab.com rate limits change on 19 October, starting with 60 requests an hour for anonymous traffic

GitLab.com rate limits change on 19 October, starting with 60 requests an hour for anonymous traffic

22 September 2026 — GitLab announced on 17 September that rate limits on GitLab.com will follow the customer's subscription. The first step lands on 19 October 2026, for Free accounts and for any request that arrives without credentials. Premium and Ultimate move in January 2027.

What changes, and when

The sharpest change is for anonymous traffic. A request with no credentials will get 60 requests per hour per IP address. GitLab's current table allows 500 requests per minute from an unauthenticated IP address, so a script that works today can fail on the first run after the change. GitLab is explicit that the cap applies wherever the request comes from, including automation running against a paid account without a token.

Signed-in traffic moves onto per-user limits by plan. GitLab's documentation gives a sustained limit of 5,000 requests an hour on Free, 15,000 on Premium and 25,000 on Ultimate, with burst limits of 100, 1,250 and 2,000 requests a minute. Today every authenticated user gets 2,000 API requests a minute. The existing limits keep applying alongside the new ones, and whichever is lower wins. A user in several top-level groups gets the highest tier available to them. Self-Managed and Dedicated instances are not affected.

The two sources differ on one point. The blog states the dates as firm. The documentation still describes the per-plan figures as proposed and not yet in effect. The January date for Premium and Ultimate has no day attached.

Who gets caught

Almost nobody browsing, pushing or running pipelines within their plan will notice, GitLab says. The traffic at risk is automation: CI jobs and scripts that call the API without a token, integrations that poll in tight loops, and busy public projects whose callers never sign in. Unauthenticated Git over HTTPS is treated differently: the documentation says it does not count against the new anonymous limit and stays on the current per-IP limit.

What to do before 19 October

• Find the anonymous callers. List every job, script and integration that talks to GitLab.com, and check whether it sends a personal access token, an OAuth token or the CI/CD job token. Any of the three moves a request onto the plan's limits.
• Handle a 429 properly. A throttled request returns 429 Too Many Requests with a Retry-After header. A client that waits for that interval and backs off exponentially recovers on its own; one that retries at once does not.
• Watch the headers. Every response carries RateLimit-Remaining, which shows how much of the current window is left.
• Use the preview windows. GitLab will switch the new Free and anonymous limits on from 15:00 to 19:00 UTC on 7 and 14 October, then off again. Run your heaviest jobs in those windows and see what fails.

If an integration genuinely cannot authenticate — a public status badge is GitLab's own example — the company asks for an email to limits@gitlab.com. It also says it is working on a way to buy capacity above plan limits, with details later this year and no price yet.

Sources

• GitLab blog, "Rate limits on GitLab.com are changing" — 17 September 2026
• GitLab Docs, "GitLab.com settings: rate limits" (read 22 September 2026) — 22 September 2026