Rate limits on GitLab.com are changingClose

To search repositories and projects, login to gitlab.com. SuggestionsGitLab Duo Agent PlatformCode Suggestions (AI)CI/CDGitLab on AWSGitLab on Google CloudWhy GitLab?

PlatformExecution & Workflows CI/CD Source Code Management Agile DeliverySecurity & Governance Application Security Testing Governance & Compliance Supply Chain SecurityContext & AI Agentic Orchestration Context Graph Visibility & MeasurementExplore the Platform Why GitLabOne platform for speed with control across your software lifecycle.Learn more SolutionsOutcomes DevOps Modernization Security Modernization AI ModernizationBy size Enterprise Small Business StartupsIndustries Financial Services Public Sector Telecommunications Automotive Education AerospaceView all Solutions GitLab TranscendCatch our latest innovations announced at the last Transcend.Read the blog PricingResourcesDiscover Docs University Demo Series Demo Hub ServicesConnect Blog Community Customers Partners EventsView all resources What’s new in GitLabStay updated with our latest features and improvements.Read the latest Company About Jobs Press Handbook Leadership Investor relations Trust Center AI Transparency Center NewsletterContact us Talk to sales Support portal Customer portal

Request a demoGet free trialSign in

EnglishDeutschGet free trial

Ship at agent speed. Prove every step. Transcend returns on October 6.Register nowBlogProductRate limits on GitLab.com are changingPublished on: September 17, 20265 min readRate limits on GitLab.com are changingStarting October 19, GitLab.com rate limits will align with your subscription. Sign in to unlock higher limits. Premium/Ultimate changes arrive in January.Sam WiskowproductGitLab.com hosts millions of projects for teams of every size that need a platform they can rely on. Demand is climbing quickly, and we expect platform load to grow several times over this year. Predictable limits are what keep GitLab.com fast for everyone on it, including the automation and agent workloads teams are building on the platform.To hold that as we scale, we're updating how rate limits work. Starting October 19, 2026, rate limits on GitLab.com will align with your subscription tier. Free accounts and unauthenticated requests happen first, on October 19. Premium and Ultimate move in January 2027.What is changingLimits align with your subscription. Free, Premium, and Ultimate subscription plans get their own limits, applied per user and per top-level group. Free takes effect October 19; Premium and Ultimate in January 2027.Signing in gets you the full limit. An authenticated request is governed by your subscription plan below. A request that arrives with no credentials gets 60 requests per hour per IP address.The per-plan limits are published in the rate limits documentation.What happens on October 19There will be two preview windows for Free and unauthenticated traffic, on October 7 and October 14 from 15:00 to 19:00 UTC. Signed-in Premium and Ultimate requests are not affected, since those limits do not change until January. Unauthenticated requests are capped no matter where they come from, including automation running against a paid account without credentials. A preview window (engineers call these brownouts) is a short, planned window where we switch the new limits on and then switch them back off. Nothing else about the service changes while it runs. The point is to give you a real look at how your own workloads behave under the new limits, weeks before they apply for good.On October 19 the new limits take effect.We set these limits by looking at how GitLab.com is actually used. Almost all users are already inside the new limits and won't notice any change. We also looked at what similar platforms allow. The Free limit and the anonymous allowance match the industry norm, while Premium and Ultimate are more generous, at levels other platforms reserve for their enterprise tiers or don't publish at all.If you're close to a limitIf you find that you are nearing a limit, authenticate your requests. It's usually a small change: Invoking a personal access token, an OAuth token, or the CI/CD job token all move a request off the anonymous 60 requests per hour and onto your plan's limits, which are much higher.Next, look at how you're calling the API. Batching, caching, and pagination go a long way, and polling in a tight loop burns through your allowance fast. When you do cross a limit, you get an HTTP 429 back with a Retry-After header saying how long to wait, so a client that reads its own response headers mostly fixes itself. Backing off exponentially recovers faster than retrying immediately.Upgrading to Premium or Ultimate increases the limits, too, per user and per top-level group.If you need a higher limit on an ongoing basis, we are working on a way to purchase capacity above the standard plan limits, with details coming later this year. If that sounds like you, reach out to your account team or email limits@gitlab.com and tell us what you need.What changes and what doesn'tThese limits are set so no single workload can slow the platform for everyone else. Ordinary signed-in work isn't the target, and, for almost all users, a normal day looks identical. Browsing the UI, working in your editor, pushing and pulling with git, and running CI/CD within your plan all carry on exactly as they do today. Some heavy automation and a small number of Free-tier workloads will reach the new ceilings.What doesn't change:You can always reach and export your own data and repositories.GitLab Self-Managed and GitLab Dedicated limits stay with your operator. This is only a GitLab.com change.We'll notify you before we make additional changes.A reminder: Make sure to authenticate your requests to GitLab.com so your limits are higher.FAQHow do I know whether this affects me?
Compare your busiest minute against the published limits for your plan. Most customers are not close. The quickest signal in the meantime is the RateLimit-Remaining header on your API responses, which tells you how much of your current window is left, and we are building a view in the product for release later this year that shows your usage against your plan's limits.My project is public and busy. What are my options?
Three things help. Ask the automation that calls your project to sign in, which moves it onto its own limits rather than the anonymous allowance. Make the project private if the traffic is not coming from the audience you built it for, which stops anonymous callers reaching it at all. Or upgrade to Premium or Ultimate for much higher limits.What if I am a member of several top-level groups?
Your user limit will be the highest subscription tier available to you. If you are a member of an Ultimate group, you will have access to the Ultimate limit.What happens when I hit a limit?
You get 429 Too Many Requests with RateLimit-* headers and a Retry-After. Wait the interval it gives you, then retry.My integration genuinely can't authenticate. What now?
Reach out to us at limits@gitlab.com. There are legitimate anonymous patterns, a public status badge being the obvious one. If you are concerned that an integration you own may be affected, contact us.Does this apply to GitLab Self-Managed or GitLab Dedicated?
No. This is a GitLab.com-only change.Additional resourcesRate limits by planAuthenticating your API requestsQuestions, or you've encountered a case we haven't thought of? Contact your account team or email limits@gitlab.com.Start your free30-day GitLab trialGitLab Duo Agent Platform accessTry our most advanced featuresAutomate complex tasks with AIGet free trialNo credit card required.More to exploreView all blog posts

ProductGitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8Read the blog

ProductMaking room for what's next in the GitLab UIRead the blog

ProductGitLab Patch Release: 19.3.1, 19.2.5, 19.1.7Read the blog

We want to hear from youEnjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.Share your feedback Start building faster todaySee what your team can do with the intelligent orchestration platform for DevSecOps.Get your free trial Contact sales

®Footer linksPricingView plansWhy Premium?Why Ultimate?Contact UsContact salesSupport portalCustomer portalStatusTerms of usePrivacy statementPlatformExplore the platformAgentic OrchestrationCI/CDContext GraphWhy GitLabTopicsCI/CDGitOpsDevOpsVersion ControlDevSecOpsCloud NativeAI for CodingAgentic AISolutionsDevOps modernizationSecurity modernizationAI modernizationFinancial servicesPublic sectorTelecommunicationsAutomotiveEducationAerospaceEnterpriseSmall businessStartupsGitOpsSoftware composition analysisValue stream managementAll solutionsResourcesInstallQuick start guidesDocsUniversityDemo SeriesDemo HubServicesBlogCommunityCustomersPartnersEventsNewsletterWhat's newAll resourcesCompanyAboutJobsPressHandbookLeadershipInvestor relationsTrust CenterAI Transparency CenterSustainabilityDiversity, inclusion and belonging (DIB)Modern Slavery Transparency Statement

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under licenseView page sourceEdit this pagePlease contribute© 2026 GitLab Inc.

Rate limits on GitLab.com are undergoing a significant change starting on October 19, 2026, wherein the rate limits will directly align with each user's subscription tier. This adjustment is being implemented to ensure platform stability and predictable performance as the demand for GitLab.com continues to grow substantially. Sam Wiskow notes that predictable limits are essential for maintaining the speed of the platform, especially concerning automation and agent workloads. The new system will apply limits based on subscription plans, governing usage per user and per top-level group for the Free, Premium, and Ultimate tiers.

Currently, the system differentiates between authenticated and unauthenticated requests. Unauthenticated requests, which arrive without credentials, are capped at sixty requests per hour per IP address. Signed-in requests, conversely, are governed by the specific limits associated with the user's subscription plan. To ensure users are aware of these changes before implementation, GitLab will introduce preview windows, or brownouts, on October 7 and October 14, from 15:00 to 19:00 UTC, allowing users to observe how their workloads behave under the new constraints.

The core philosophy behind these changes is to prevent any single workload from degrading the performance for the entire platform. For the vast majority of users, such as those performing standard activities like browsing the user interface, editing code, or running CI/CD jobs within their plan, the experience will remain virtually identical. The changes primarily affect heavy automation tasks and a smaller subset of Free-tier workloads.

To effectively manage usage under the new limits, users are advised to authenticate their requests to GitLab.com, utilizing personal access tokens or OAuth tokens for actions like invoking a CI/CD job. This action shifts the request from the anonymous allowance to the user's higher, plan-specific limits. Furthermore, techniques such as batching, caching, and pagination are recommended to reduce request volume. When a client exceeds a limit, it will receive an HTTP 429 Too Many Requests response, which includes a Retry-After header indicating the necessary waiting interval. Clients are advised to implement exponential backoff when retrying to recover more efficiently.

For users requiring consistently higher throughput, upgrading to the Premium or Ultimate plans will result in significantly increased limits, applied per user and per top-level group. GitLab is also developing a mechanism for purchasing capacity beyond standard plan limits, which will be detailed in subsequent announcements. It is important to note that these rate limit adjustments apply exclusively to GitLab.com; limits for GitLab Self-Managed and GitLab Dedicated instances remain independent of this change. Users should monitor the RateLimit-Remaining header in API responses as an immediate indicator of their usage relative to their allocated allowance.