The first limits arrive on 19 October
GitLab says GitLab.com will begin tying request quotas to subscription tier on 19 October 2026. Free accounts and unauthenticated traffic move first, while Premium and Ultimate accounts are scheduled to adopt their tier-specific limits in January 2027. Two four-hour brownouts on 7 and 14 October, from 15:00 to 19:00 UTC, will temporarily activate the new Free and anonymous rules so operators can see whether their workloads hit them before permanent enforcement.
The change is specific to GitLab.com. GitLab Self-Managed and GitLab Dedicated remain governed by the limits configured by their operators. GitLab also says ordinary signed-in browsing, Git pushes and pulls, and CI/CD activity within a plan are expected to continue normally for almost all users; the more exposed cases are heavy automation and workloads that currently call public projects without credentials.
The quotas distinguish sustained traffic from short bursts
GitLab's current documentation lists proposed sustained authenticated limits of 5,000 requests per hour for Free, 15,000 for Premium and 25,000 for Ultimate. Anonymous traffic is proposed at 60 requests per hour per IP address regardless of plan. Separate burst ceilings are 100 authenticated requests per minute on Free, 1,250 on Premium and 2,000 on Ultimate, but GitLab says the hourly allowance is the figure to plan sustained workloads around.
The new plan limits cover API requests, web requests and authenticated Git over HTTPS. Existing endpoint-specific and platform limits continue to apply alongside them, with the lower applicable ceiling taking effect. Unauthenticated Git over HTTPS is treated separately and remains subject to the existing per-IP Git limit rather than the new 60-per-hour anonymous allowance.
Authentication becomes part of automation capacity
For bots, integrations and coding agents, the main operational distinction is whether requests carry credentials. GitLab says a personal access token, OAuth token or CI/CD job token moves a request from the 60-per-hour anonymous pool onto the user's plan allowance. Automation associated with a paid account still counts as anonymous when it sends no credentials.
When a workload exceeds a limit, GitLab.com returns HTTP 429 with a Retry-After value and related rate-limit headers. GitLab recommends caching, batching, pagination, monitoring RateLimit-Remaining and exponential backoff. It is also designing a way for customers to buy additional sustained capacity above standard plan limits, but pricing and availability have not yet been published.
The numbers are announced, but they are not live yet
The rate-limit documentation labels the tier-aware figures as proposed until their rollout dates, and the October brownouts can still reveal operational problems that cause GitLab to adjust implementation details. Existing limits remain in force today and continue to coexist with the new rules after launch.
The confirmed change is therefore the published GitLab.com schedule, the current proposed quotas and the authentication model around them. The useful next evidence will come from the October brownouts, any revisions GitLab makes before 19 October, and real workload measurements from integrations that currently depend on anonymous or high-frequency access.