# GitLab's 60-Request Limit Can Break the Wrong Script First **Summary:** GitLab will cut anonymous traffic from 500 requests a minute to 60 an hour per IP on October 19. I would use its two October brownouts to find unauthenticated callers before a shared address hides the cause. - Canonical: https://markhuang.ai/news/gitlab-60-request-limit-anonymous-scripts - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-17 - Section: News - Tags: GitLab, Rate Limits, API Automation, Authentication, DevOps - Source: [GitLab Blog](https://about.gitlab.com/blog/rate-limit-change-2026/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![Many automated request streams converge on one narrow network gate while separate authenticated streams pass through dedicated channels](https://cdn.markhuang.ai/news/gitlab-60-request-limit-anonymous-scripts/hero.webp) *Anonymous requests can come from many machines and still arrive as one identity. When the quota belongs to the IP address, they all wait at the same gate.* [GitLab says its GitLab.com rate limits will change on October 19, 2026](https://about.gitlab.com/blog/rate-limit-change-2026/). Anonymous traffic will receive 60 requests per hour per IP address, down from the current general limit of 500 requests per minute. Free accounts move to plan-based limits on the same day. Premium and Ultimate follow in January 2027. I read this as an identity audit more than a capacity change. Any automation I own should authenticate. The harder question is what else shares its public IP, because one forgotten script can spend the allowance for every unauthenticated process behind the same office gateway, cloud NAT, or proxy. ## Sixty requests can belong to a whole network The units tell the story. GitLab's [current documentation](https://docs.gitlab.com/user/gitlab_com/rate_limits/) lists 500 unauthenticated requests per minute per IP. The incoming allowance is 60 per hour. A poller that runs once a minute can consume an IP's entire anonymous budget by itself. [GitHub provides the obvious comparison: 60 unauthenticated REST API requests per hour](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api), also tied to the originating IP. That makes GitLab's claim that the anonymous allowance matches an industry norm credible. Teams still have to find and fix the callers that assumed a far larger pool. The IP boundary is the catch. GitLab's support guidance warns that people and automated processes behind the same NAT or office address share the allowance. A developer checking public project data, a status page, and a scheduled inventory script can look unrelated inside the network while GitLab sees one anonymous caller. The first failure may therefore appear in a client that did very little. ## The brownouts are production tests GitLab will enable the new Free and anonymous limits during two preview windows: October 7 and October 14, from 15:00 to 19:00 UTC. The company calls them brownouts, then switches the limits off again before permanent enforcement on October 19. I would treat those eight preview hours as an outage drill. Record every `429 Too Many Requests` response, the calling job, its authentication state, and its egress IP. Check whether the client honors `Retry-After`. Watch for work that becomes late or silently partial, not only jobs that fail loudly. > **Info:** > > I will call the test a pass when every owned caller has an identity, every intentionally anonymous caller has a measured budget, and a `429` produces a bounded delay instead of a retry storm. A green dashboard alone tells me very little. GitLab's published headers need a cautious reading. The plan-limit documentation says responses include remaining-quota and reset information, but it also notes that some endpoint-specific limits are not reflected in those headers. A healthy `RateLimit-Remaining` value on one response cannot prove that the next request will avoid every other throttle. ## Authentication trades quota risk for credential risk GitLab's proposed plan limits are much roomier for authenticated traffic: 5,000 requests per hour for Free, 15,000 for Premium, and 25,000 for Ultimate. The burst ceilings are 100, 1,250, and 2,000 requests per minute, respectively. The hourly limit takes precedence, and existing endpoint-specific limits still apply when they are lower. Moving a script onto a token is the obvious fix, but I would not scatter personal access tokens through cron jobs just to make the `429` disappear. GitLab lists personal, project, OAuth, deploy, and CI/CD job credentials for different contexts. I would give each job the narrowest suitable identity, then record its owner, scope, rotation, and revocation path. Authentication changes the failure mode. Anonymous automation risks sharing a tiny quota. Authenticated automation can carry authority it did not need before. A public metadata reader should not receive write access because a broad token was convenient. ## Backoff protects the service, not the workload GitLab recommends batching, caching, pagination, and exponential backoff. Those are sound client behaviors. A throttled response includes `Retry-After`, and a client should wait rather than hammer the same endpoint. Still, retry logic cannot create capacity. If an anonymous status collector needs 120 requests every hour, polite backoff only spreads the failure across more time. The workload must authenticate, make fewer calls, or obtain a different arrangement. GitLab says integrations that genuinely cannot authenticate should contact the company, and its handbook says published limits do not receive bypasses. There is an unfinished commercial piece too. GitLab says it is designing a way to buy capacity above standard plan limits, with details due later in 2026. Its product view for comparing usage with plan limits is also still planned for later this year. I would not build an operating plan around either feature until GitLab publishes the contract and price. ## What I would do before October 7 I would begin at the network edge, not in the GitLab settings page. List the public IPs used by offices, runners, serverless jobs, and cloud networks. Search job definitions and scripts for calls to `gitlab.com` that lack an authorization header or an appropriate Git credential. Then group the results by caller and business purpose. Owned automation should receive a suitable machine identity. Repeated reads should use caching or conditional requests where the endpoint supports them. Each client should log status, relevant rate-limit headers, and enough caller context to trace a spike without recording secrets. Alerting should distinguish a deliberate throttle from a GitLab incident. I would keep some callers anonymous on purpose. Public badges, external monitors, and software run by people I do not control may have a legitimate reason to access public data without a token. Those cases need a budget and a degradation path. They should not be hidden inside the same retry policy as an internal job that can authenticate. The new limit is defensible as a platform safeguard, especially as automated traffic grows. I would use the October brownouts to discover which systems still rely on a shared, anonymous identity. Then I would assign proper credentials where they belong and preserve anonymous access only where it is intentional.