GitLab is changing how rate limits work on GitLab.com, and the company is letting everyone watch the preview before the curtain rises. Starting October 19, 2026, the limits on GitLab.com will align with your subscription tier. Free accounts and unauthenticated requests start first, on October 19. Premium and Ultimate plans move in January 2027.
Preview Windows
Two brief preview windows for Free and unauthenticated traffic are being held by the company, on October 7 and October 14, from 15:00 to 19:00 UTC. During these windows, GitLab turns the new limits on and then turns them back off, which is known as a brownout. No other part of the service changes while they run.
The idea is to let users see firsthand how their own workloads actually perform under the new limits, weeks ahead of when they go into effect.
Limits by Plan
Each free account comes with its own restrictions, assigned individually to users and to top-level groups. The free plan’s rules take effect from October 19. Requests made without any credentials attached receive 60 requests per hour per IP address.
These higher limits are what sets Premium and Ultimate apart, and the company points out that other platforms only make room for such figures within their own enterprise tiers, or else they keep them under wraps entirely.
The per-plan limits are published in the rate limits documentation.
How to Stay Above the Ceiling
When approaching a boundary, switch to a verified request instead of an unverified one. A personal access token, an OAuth token, or the CI/CD job token each take a request away from the anonymous 60 requests per hour and put it under your plan’s limits, which are far greater.
Batching, caching, and pagination help. Polling in a tight loop burns through your allowance fast. When you cross a limit, you get an HTTP 429 Too Many Requests with a Retry-After header saying how long to wait. A client that reads its own response headers mostly fixes itself. Backing off exponentially recovers faster than retrying immediately.
Moving up to Premium or Ultimate raises the caps for each individual user and each top-level group.
What Does Not Change
The everyday experience for most people stays untouched. Signing in to work normally doesn’t change anything. Browsing through the interface, editing files, sending code changes through git, and running CI/CD inside your plan all continue exactly as they did before.
A few workloads on the Free tier will hit the new limits, alongside automation that handles much of the work.
Before you send a request to GitLab.com, confirm that it has been authenticated. This step raises the number of requests you can make within a given period.
Key Facts Box
- Free limit and anonymous allowance match the industry norm
- Premium and Ultimate are more generous than similar platforms
- Free takes effect October 19, 2026
- Premium and Ultimate move in January 2027
- Brownout previews: October 7 and October 14, 15:00 to 19:00 UTC
- Unauthenticated requests are capped at 60 per hour per IP address
Our View
Before the new limits come into play, the firm is showing brownout previews to Free and unauthenticated traffic. This gives users a chance to watch how their workloads react when they hit those ceilings.
Predictable boundaries are the stated aim here, and free users who remain beneath the ceiling will see no change at all. Should integrations fail to authenticate, GitLab points them toward limits@gitlab.com for an exception instead.
Source material: “Rate limits on GitLab.com are changing,” gitlab.com.
Get the Notebook.
The day's best stories and every fresh verdict, in plain English, in your inbox by seven. One email a day, no more.