GitLab Is Cutting Unauthenticated API Access by 500x. Here's Your Testing Window Before It's Permanent.

If any script, bot, or agent in your pipeline talks to GitLab.com without authenticating, the number worth knowing is this: unauthenticated requests drop from 500 per minute to 60 per hour per IP address on October 19. That’s not a typo — roughly a 500x cut for anyone not sending credentials. GitLab is giving everyone two real chances to test against the new limits before they become permanent, and the first one is October 7.

The actual numbers and dates

• Announced: September 17, 2026, via GitLab’s own blog.
• Brownout windows: October 7 and October 14, 15:00–19:00 UTC, four hours each. During these windows, the new limits switch on temporarily for Free-tier and unauthenticated traffic, then switch back off. This is explicitly your cheapest production test of the year — GitLab is handing you a scheduled rehearsal for free.
• Permanent enforcement: October 19, 2026, for Free-tier and unauthenticated traffic.
• Premium and Ultimate authenticated limits: don’t change until January 2027 — a meaningfully longer runway if you’re on a paid tier.
• Not affected at all: GitLab Self-Managed and GitLab Dedicated deployments. This is a GitLab.com (the hosted SaaS product) change only.

Per-minute burst limits across the tiers are set at 100, 1,250, and 2,000 requests respectively, so this isn’t just the unauthenticated case — authenticated traffic on lower tiers has real ceilings too, just less dramatic ones than the unauthenticated cut.

Why this is happening now

GitLab’s own framing is direct: it’s forecasting several times more traffic in 2026, driven largely by AI coding agents and automated development tools. This isn’t a GitLab-specific overreaction — the company explicitly groups itself with Anthropic and GitHub, both of which have introduced comparable rate limits for the same underlying reason. The pattern across this site’s coverage all month has been about agents gaining more capability and more standing access (Codex in the cloud, Claude Code cloud sessions, Amazon opening Seller Central to agents, OpenAI’s dots connecting to 4,000+ apps). This is the infrastructure side of that same trend: the platforms underneath all that agent activity are now defensively throttling against the traffic it generates.

A real, specific example of exactly this failure mode already happened inside GitLab’s own infrastructure: a production incident from earlier this year traced a surge of rate-limit errors on GitLab’s AI Gateway and Duo Workflow Service back to a single external IP running automated trial accounts, which sent over 68% of requests to GitLab’s own Duo Agent Platform proxy endpoint — exhausting the shared model quota for everyone else. That’s not a hypothetical concern driving this policy. It’s the exact pattern GitLab experienced on itself.

Who actually needs to act

GitLab’s own position is that almost all users are already inside the new limits and won’t notice anything. That’s likely true for typical interactive usage. The actual exposure is narrower and specific:

• Any script, CI job, or agent calling GitLab.com’s API without an access token — this is the group facing the full 500x cut, and it’s exactly the kind of traffic unmonitored automation tends to generate.
• Free-tier accounts running heavy automated workloads — bulk scraping, polling, or bot traffic that’s been relying on the free tier’s previous generosity.
• Anyone building a tool, integration, or package that queries GitLab’s API (release metadata, star counts, CI status) without requiring users to supply their own token — this shifts from a convenience to a potential breaking change for your own downstream users, not just for you.

If you don’t fall into one of those three categories, this genuinely may not affect you — but “probably fine” isn’t the same as “confirmed fine,” and the brownout windows exist specifically so you don’t have to guess.

What to actually do

1. Use the October 7 and 14 windows deliberately. Mark 15:00–19:00 UTC on both dates and run your actual automation against GitLab.com during those windows. This is a real, scheduled opportunity to see 429 responses before they cost you anything in production.
2. Authenticate everything you can. The unauthenticated ceiling is brutal by design — moving any automated traffic to an authenticated request with a token immediately moves you to the much higher per-tier limit instead of the 60-per-hour floor.
3. Handle HTTP 429 properly. Exceeding a limit returns a 429 with a Retry-After header — if your current error handling doesn’t read and respect that header, this is the moment to fix it, not after October 19.
4. Apply GitLab’s own recommended mitigations: cache frequently-requested data instead of re-fetching it, batch API operations instead of firing them individually, and reduce unnecessary polling frequency. All three directly reduce your request count without reducing what your automation actually accomplishes.
5. If you’re genuinely going to exceed the new limits even after optimizing, GitLab has stated a paid capacity add-on and a usage-monitoring dashboard are coming — and limits@gitlab.com is the address GitLab itself gave for this exact situation.

Official reference: GitLab’s own announcement (about.gitlab.com/blog/rate-limit-change-2026), cross-checked against DevOps.com, InfoWorld, and WorkOS’s technical breakdown, all dated September-October 2026. Confirm current limits directly against GitLab’s documentation before the October 19 enforcement date, since specific tier numbers are the kind of detail that can be refined before a hard deadline.