GitLab.com Rate Limits Change October 19: Prepare Automation and AI Agents
GitLab.com will introduce subscription-tier rate limits beginning October 19, 2026, first for Free accounts and unauthenticated requests. Premium and Ultimate accounts move to the new limits in January 2027. GitLab says the policy applies to API requests, web traffic and authenticated Git over HTTPS on its hosted service, with limits enforced per user and per top-level group where applicable.
The immediate migration issue is unauthenticated automation. Requests without credentials will be limited to 60 requests per hour per IP address, including automation that accesses a paid account without authenticating. GitLab will run preview windows on October 7 and October 14 from 15:00 to 19:00 UTC before the October 19 rollout.
GitLab says almost all current users are already within the new limits. Workloads most likely to require changes are polling integrations, repository scanners, bots and AI-agent systems that make repeated GitLab.com requests without credentials or generate unusually high request volumes.
Rollout schedule
| Date | Change |
|---|---|
| October 7, 2026, 15:00–19:00 UTC | Preview window for Free and unauthenticated traffic |
| October 14, 2026, 15:00–19:00 UTC | Second preview window |
| October 19, 2026 | New limits take effect for Free accounts and unauthenticated requests |
| January 2027 | Premium and Ultimate move to subscription-tier limits |
The change applies to GitLab.com. GitLab Self-Managed and GitLab Dedicated remain under limits controlled by their operators.
The 60-requests-per-hour boundary matters for automation
GitLab's announcement sets unauthenticated traffic at 60 requests per hour per IP address. A bot or agent can therefore consume the shared anonymous allowance even when it is operating around repositories owned by a paid account if its requests contain no credentials.
Authentication moves requests onto the applicable subscription allowance. GitLab specifically identifies personal access tokens, OAuth tokens and CI/CD job tokens as ways to authenticate API workloads.
This distinction matters for AI coding and platform agents because a single workflow can perform repository discovery, issue and merge-request reads, file retrieval, status polling and follow-up actions. Multiple workers behind one outbound IP can also compete for an IP-based anonymous allowance.
What happens when a client reaches the limit
GitLab.com returns HTTP 429 Too Many Requests when a workload crosses an applicable rate limit. Responses include RateLimit-* headers and a Retry-After value indicating how long the client should wait.
Automation should treat those headers as control-plane data. A resilient client should stop immediate retries, wait for the indicated interval and use exponential backoff for subsequent failures. GitLab also recommends batching, caching and pagination to reduce unnecessary request volume.
Tight polling loops deserve particular attention. Repeatedly checking a repository, pipeline, issue or merge request for a state transition can consume request capacity without producing additional useful work. Event-driven integrations, webhooks and bounded polling intervals can reduce that load where the workflow supports them.
Migration checklist for bots and AI agents
1. Inventory unauthenticated GitLab.com traffic
Identify CI scripts, cron jobs, agent tools, MCP integrations, repository scanners and internal services that call GitLab.com. Record whether each request path supplies credentials and which outbound IPs are shared by multiple workers.
2. Authenticate machine workloads
Use an authentication mechanism appropriate to the workload and grant the narrowest scopes required. Personal access tokens can suit user-bound automation, OAuth can suit delegated applications, and CI/CD job tokens can suit supported pipeline-to-GitLab operations.
Credential management should remain separate from agent prompts and generated content. Store tokens in the relevant secret-management or CI credential facility and rotate them according to the organization's normal policy.
3. Measure request behavior during the preview windows
The October 7 and October 14 windows provide a controlled opportunity to observe Free-tier and anonymous workloads under the forthcoming limits. Capture 429 responses, RateLimit-Remaining, Retry-After, request volume and job completion rates.
GitLab says RateLimit-Remaining is the quickest current signal for comparing usage against available capacity. That makes the preview windows useful for finding integrations that rely on assumptions about effectively unrestricted anonymous traffic.
4. Reduce avoidable requests
Cache stable repository metadata, paginate efficiently, batch operations where supported and replace aggressive polling with events or longer intervals. Agent orchestration should also avoid multiple workers independently fetching the same repository state when a shared cache or coordinator can reuse it.
5. Implement explicit 429 handling
A production integration should interpret Retry-After and back off instead of retrying immediately. This prevents a rate-limit event from becoming a retry storm and gives long-running agent workflows a predictable recovery path.
Premium and Ultimate have more time
Authenticated Premium and Ultimate traffic is outside the October rollout and moves to the new subscription-tier model in January 2027. That later date gives larger deployments additional time to profile API and Git usage.
GitLab says limits are applied per user and per top-level group, while a user's available user limit follows the highest subscription tier available to that user. Teams should consult GitLab's current rate-limit documentation for the numeric plan limits because those values are operational configuration and may be revised independently of the rollout announcement.
GitLab is also developing a way for customers to purchase capacity above standard plan limits. The company says details are expected later in 2026 and directs customers with ongoing higher-capacity requirements to their account team.
Why GitLab is changing the limits
GitLab attributes the change to rapidly increasing platform demand and says it expects GitLab.com load to grow several-fold during 2026. The company explicitly includes automation and agent workloads among the traffic patterns it is preparing to support.
The operational consequence is straightforward: GitLab.com integrations now need to treat request capacity as a defined resource. Authentication, caching, backoff and request observability become more important as autonomous developer tooling increases the number of machine-generated interactions with source-control platforms.
Bottom line
GitLab.com begins its new rate-limit rollout on October 19, 2026, after preview windows on October 7 and October 14. Unauthenticated traffic will receive 60 requests per hour per IP address, while authenticated requests use subscription-based limits. Premium and Ultimate transition in January 2027.
Teams running bots, scanners or AI agents should identify anonymous calls now, authenticate machine workloads, monitor rate-limit headers during the preview windows and make 429/backoff handling part of the integration path. Self-Managed and Dedicated deployments remain governed by their operators.
Sources
- GitLab — Rate limits on GitLab.com are changing: https://about.gitlab.com/blog/rate-limit-change-2026/
- GitLab documentation — Rate limits on GitLab.com: https://docs.gitlab.com/user/gitlab_com/#rate-limits-on-gitlabcom
- InfoWorld — GitLab joins rush to slow AI coders with rate limits: https://www.infoworld.com/article/4223949/gitlab-joins-rush-to-slow-ai-coders-with-rate-limits.html