GitLab.com will modify how it enforces request limits beginning October 19, 2026, aligning caps with each subscription tier. Free accounts and unauthenticated traffic will face new restrictions on that date, while Premium and Ultimate users will see changes in January 2027. The adjustment aims to preserve performance as platform usage expands, particularly for automated workflows and agent-based processes.

Under the new structure, each subscription level receives distinct limits applied per user and per top-level group. Free users will be subject to a cap of 60 requests per hour per IP address when not signed in. Authenticated requests will draw from plan-specific limits, which vary by tier. These thresholds are documented in GitLab’s rate limits guidelines.

To ease the transition, two preview periods are scheduled for October 7 and 14, from 15:00 to 19:00 UTC. During these windows, the updated limits will be temporarily enforced before being reverted, allowing users to observe how their workloads respond. The changes are limited to GitLab.com; self-managed and dedicated instances remain unaffected.

GitLab emphasizes that typical user activity — such as browsing the interface, using version control, or running CI/CD pipelines — will continue without disruption. The limits are designed to prevent individual workloads from degrading service for others. Most users, the company states, operate well within the new boundaries.

Users approaching their threshold are advised to authenticate requests using personal access tokens, OAuth tokens, or CI/CD job tokens. This shifts traffic from the anonymous allowance to their plan’s allocated limits, which are significantly higher. Optimizing API usage through batching, caching, and pagination can also reduce strain. When limits are exceeded, responses include a 429 status code and a Retry-After header, enabling automated clients to adjust dynamically.

Premium and Ultimate subscribers gain access to higher per-user and per-group limits. For those requiring sustained capacity beyond standard tiers, GitLab plans to introduce options for purchasing additional quota later in the year. Affected users are encouraged to contact their account team or email limits@gitlab.com for guidance.

The changes do not impact public repositories managed by multiple groups in the same way. A user’s effective limit will reflect the highest tier they belong to across top-level groups. For example, membership in an Ultimate group grants access to Ultimate-tier limits.

If a request fails due to rate limiting, the response includes RateLimit-Remaining and Retry-After headers, indicating remaining capacity and recommended wait time. Persistent issues or edge cases — such as public projects experiencing high traffic — may prompt outreach to GitLab support. Public, non-authenticated endpoints, like status badges, are considered valid anonymous use cases.

GitLab has confirmed this update applies exclusively to GitLab.com and does not extend to self-hosted or dedicated deployments. Documentation outlining plan-specific limits will be published ahead of the October 19 rollout. Users are reminded to authenticate API calls to ensure access to higher rate limits and better performance monitoring tools are forthcoming.