GitLab.com Implements Tiered Rate Limits Based on Subscription
New rate limits align with subscription tiers to maintain platform performance.
1Subscription-based rate limits
GitLab.com is introducing tiered rate limits based on subscription plans, effective October 19, 2026. Free accounts and unauthenticated requests will be limited to 60 requests per hour per IP address. Premium and Ultimate tiers will follow in January 2027 with higher limits. This change aims to maintain platform performance as user demand grows. The limits apply per user and per top-level group, with authenticated requests receiving full subscription benefits.
2Preview windows for testing
Two preview windows for Free and unauthenticated traffic are scheduled for October 7 and 14, 2026, from 15:00 to 19:00 UTC. These 'brownouts' allow users to test workloads under new limits before permanent implementation. Premium and Ultimate users remain unaffected until January 2027. The temporary windows provide real-world data on how automation and workflows behave under the new constraints without permanent impact.
3Authentication advantages
Authenticated requests receive significantly higher rate limits than anonymous access. Using personal access tokens, OAuth tokens, or CI/CD job tokens moves requests from the restrictive 60/hour limit to plan-specific allowances. GitLab recommends reviewing API call patterns, as techniques like batching, caching, and pagination can optimize usage. Clients receiving HTTP 429 responses should implement exponential backoff for faster recovery.
4Enterprise-level allowances
GitLab's Premium and Ultimate tiers offer more generous limits than industry standards, matching what competitors reserve for enterprise plans. The company analyzed actual platform usage and competitor benchmarks to set these thresholds. Most users already operate within the new limits and won't experience changes. Heavy automation and certain Free-tier workloads may need adjustments to comply with the new ceilings.
5Mitigation strategies
Users approaching limits can authenticate requests, make projects private, or upgrade subscriptions. GitLab is developing a capacity purchase option for needs exceeding standard limits. The RateLimit-Remaining header provides real-time usage feedback, with a comprehensive usage dashboard planned for later release. Members of multiple top-level groups inherit the highest available subscription limit.
6Exclusions and legacy systems
The changes apply only to GitLab.com, leaving Self-Managed and Dedicated instances unaffected. Core functionalities like UI browsing, code editing, and git operations remain unchanged. Users retain full access to their data and repositories. GitLab will notify users before implementing additional changes and encourages feedback for edge cases through [email protected].
7Handling rate limit hits
When hitting limits, clients receive HTTP 429 responses with Retry-After headers indicating wait times. GitLab recommends implementing client-side header reading for automatic recovery. For legitimate anonymous use cases like public status badges, users can contact GitLab for exceptions. The company acknowledges some integrations may require special consideration and invites dialogue about unique scenarios.
8Platform scalability focus
These changes reflect GitLab's commitment to maintaining performance as platform load grows. By preventing single workloads from affecting all users, the update prioritizes consistent experience for ordinary work. While most workflows remain unchanged, the tiered system creates sustainable growth parameters. GitLab positions this as necessary infrastructure for anticipated demand increases throughout 2026-2027.
Original article: GitLab — GitLab.com Implements Tiered Rate Limits Based on Subscription