Published on: September 17, 2026
5 min read
Starting October 19, GitLab.com rate limits will align with your subscription. Sign in to unlock higher limits. Premium/Ultimate changes arrive in January.
GitLab.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.
Limits 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.
There 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 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.
These 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:
A reminder: Make sure to authenticate your requests to GitLab.com so your limits are higher.
How 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.
limits@gitlab.com
.Start your free
30-day GitLab trial
No credit card required.
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedbackStart building faster today
See what your team can do with the intelligent orchestration platform for DevSecOps.
Facts Only
* GitLab.com is implementing rate limits aligned with subscription tiers.
* Free account and unauthenticated request limits begin October 19, 2026.
* Premium and Ultimate subscription limits begin January 2027.
* Unauthenticated requests are limited to 60 requests per hour per IP address.
* Limits are applied per user and per top-level group.
* Preview windows for Free and unauthenticated traffic occur October 7 and October 14 from 15:00 to 19:00 UTC.
* Users reaching a limit receive an HTTP 429 response with a Retry-After header.
* API responses include a RateLimit-Remaining header.
* Authentication methods include personal access tokens, OAuth tokens, and CI/CD job tokens.
* These changes apply exclusively to GitLab.com, not GitLab Self-Managed or GitLab Dedicated.
* A contact email for limit concerns is limits@gitlab.com.
Executive Summary
GitLab.com is transitioning to a tiered rate-limiting system to manage increasing platform load and ensure stability for all users. Starting October 19, 2026, limits for Free accounts and unauthenticated users will be enforced, followed by Premium and Ultimate tiers in January 2027. Unauthenticated traffic faces the strictest cap of 60 requests per hour per IP, while authenticated requests move to higher limits based on the user's specific subscription plan.
To mitigate disruption, the platform is conducting "brownout" preview windows in early October to allow users to observe how their workloads behave under the new constraints. Users are encouraged to authenticate their API calls and optimize their integration patterns through batching and caching to avoid 429 "Too Many Requests" errors. While most standard users are expected to remain unaffected, heavy automation and some Free-tier workloads will likely encounter these new ceilings. Options for those exceeding limits include authenticating requests, upgrading subscription tiers, or contacting GitLab for specific anonymous integration needs.
Full Take
The strongest version of this narrative is a necessary infrastructure upgrade: as a platform scales to millions of projects, predictable resource consumption is required to prevent a small number of high-intensity workloads from degrading the experience for the general population. This is a standard evolution for SaaS platforms managing "noisy neighbor" problems.
However, the framing employs a specific persuasion vector. By benchmarking limits against "industry norms" and describing Premium/Ultimate tiers as "generous," the narrative positions the change not as a restriction, but as a fair alignment with market standards. The focus on "unlocking" higher limits through sign-ins and upgrades subtly shifts the perception of a cap into a reward for paid tiers.
Patterns detected: ARC-0051 Authority Game
The root cause is the tension between providing a "Free" public utility and maintaining a sustainable commercial cloud. This echoes the broader industry trend of "degrowth" for free tiers—where features or limits are tightened to nudge users toward paid conversions under the guise of platform stability. The cost is borne by open-source maintainers and hobbyists who rely on anonymous or free API access for public projects.
Bridge Questions:
1. How do these "industry norm" limits specifically compare to competitors like GitHub or Bitbucket?
2. What is the actual threshold where a "normal day" becomes "heavy automation" for a Free user?
Counterstrike Scan: A coordinated campaign to push this would frame a pricing hike as a "stability update" to avoid churn. While this is a vendor announcement, it remains a transparent policy update rather than a deceptive influence operation.
Sentinel — Human
This analysis appears to be authentic communication from a platform service provider detailing upcoming operational changes, exhibiting the clarity and specificity expected from an internal or highly vetted external source.