Update: Evolution of Rate Limits on GitLab.com

Published: September 17, 2026 | Reading Time: $\approx 5$ minutes Author: Sam Wiskow (Product)

GitLab.com serves as the backbone for millions of projects across diverse team sizes. To ensure the platform remains fast and reliable as demand scales—especially with the rise of AI agents and heavy automation—we are restructuring our rate-limiting system.

Starting October 19, 2026, rate limits will be tied directly to your subscription tier.

📅 The Rollout Timeline

The transition will happen in stages to minimize disruption.

Key Dates at a Glance

🛠️ How the New Limits Work

The logic is simple: the more robust your plan, the higher your ceiling.

1. Unauthenticated Requests: Any request lacking credentials is capped at 60 requests per hour per IP.
2. Authenticated Requests: These are governed by your specific plan (Free, Premium, or Ultimate).

What is a "Preview Window"? Engineers often call these "brownouts." They are brief, intentional periods where new limits are toggled on and then off. This allows you to observe how your specific workloads react before the limits become permanent.

Preview Windows for Free/Anonymous traffic:

• October 7: 15:00 to 19:00 UTC
• October 14: 15:00 to 19:00 UTC

⚠️ Managing Your Limits

While most users will see no change, some high-volume automation or Free-tier users may hit these ceilings. If your request rate $R$ exceeds the plan limit $L$ (where $R > L$), you will encounter an HTTP 429 error.

How to avoid limits:

• Authenticate everything: Use a Personal Access Token (PAT), OAuth token, or CI/CD job token. This moves you from the 60 req/hr anonymous limit to your much higher plan limit.
• Optimize your code: Implement batching, caching, and pagination.
• Avoid tight loops: Polling the API constantly will exhaust your quota rapidly.
• Implement Exponential Backoff: Instead of retrying immediately, increase the wait time between attempts.

Handling a 429 Too Many Requests response:

When you hit a limit, GitLab provides a Retry-After header. Your client should read this to determine when to resume.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 3600
RateLimit-Remaining: 0

{
  "error": "Rate limit exceeded"
}

🔍 What is (and isn't) Changing?

We are trying to slow down regular users. Actually, the target is heavy automation. For the vast majority of people, a typical workday will remain identical.

No change for:

• Standard UI browsing.
• IDE integrations.
• git push and git pull operations.
• Standard CI/CD pipeline execution.
• Data exports and repository access.
• GitLab Self-Managed and GitLab Dedicated (limits remain with the operator).

🚀 Next Steps and Support

If you are a member of an Ultimate group, you will benefit from the Ultimate limit regardless of your individual status. If you have a legitimate need for capacity beyond the standard tiers, we are developing a way to purchase additional capacity later this year.

Immediate Actions:

1. Check your RateLimit-Remaining header in API responses.
2. Ensure all automation is signed in.
3. If traffic is unintended, make the project private to block anonymous callers.

Need help?

• Contact your account team.
• Email limits@gitlab.com.
• Consult the [Rate limits by plan documentation].

---

Explore More:

• Product Update: AI credit tracking and team caps.
• Product Update: GitLab Duo CLI for goal-oriented tasks.
• Security: Critical Patch Release 19.3.2, 19.2.6, 19.1.8.

Feedback? Join the conversation in the GitLab community forum!