GitLab Rate Limits Drop October 19: Fix Your Pipelines Now

GitLab announced this week that API rate limits are changing on October 19, 2026 — and if your pipelines, scripts, or automation make unauthenticated calls to the GitLab API, you have 32 days to fix it. The biggest change: unauthenticated requests drop from 500 per minute to 60 per hour per IP address. That is not a typo. One monitoring script polling every 30 seconds burns through 120 requests per hour — double the new cap — and your entire unauthenticated quota for that IP is gone.

Two “brownout” preview windows on October 7 and October 14 (15:00-19:00 UTC) will temporarily enforce the new limits before the permanent switch. GitLab says “almost all users are already inside the new limits” — technically true for humans clicking around a browser. For automation, the situation is different.

What’s Actually Changing

The core shift is from flat-rate limits to subscription-tier limits. Free, Premium, and Ultimate plans each get their own authenticated request allowances, applied per user and per top-level group. Here is what that looks like after October 19 according to the GitLab rate limit documentation:

• Unauthenticated (all plans): 60 requests per hour per IP
• Free (authenticated): 5,000 per hour sustained, 100 per minute burst
• Premium (authenticated): 15,000 per hour sustained, 1,250 per minute burst
• Ultimate (authenticated): 25,000 per hour sustained, 2,000 per minute burst

Premium and Ultimate limits take effect in January 2027, so those teams have more runway. Free-tier users face the October 19 deadline. The unauthenticated cap aligns GitLab with GitHub’s model — also 60 unauthenticated requests per hour — so this is an industry convergence more than a cash grab. However, if you relied on GitLab’s previous generosity of 500 requests per minute, the adjustment is severe.

One important note for self-managed GitLab users: none of this applies to you. These limits are GitLab.com only. Your self-managed instance operates under whatever limits your administrator has configured.

How to Fix It Before October 19

The fix is almost always the same: authenticate your requests. Switching from unauthenticated to authenticated Free tier moves you from 60 requests per hour to 5,000 per hour — 83 times more headroom, at zero cost. GitLab supports three authentication methods for API calls, as documented in the REST API authentication guide:

# BEFORE: unauthenticated — hits 60/hour cap starting Oct 19
curl "https://gitlab.com/api/v4/projects/123/releases"

# FIX 1: Personal Access Token (PAT)
curl -H "PRIVATE-TOKEN: $GITLAB_PAT" \
  "https://gitlab.com/api/v4/projects/123/releases"

# FIX 2: CI/CD Job Token (use inside .gitlab-ci.yml)
curl -H "JOB-TOKEN: $CI_JOB_TOKEN" \
  "https://gitlab.com/api/v4/projects/123/releases"

For CI/CD pipelines specifically, check your .gitlab-ci.yml for any curl or API calls that do not use $CI_JOB_TOKEN, $CI_REGISTRY_USER, or a stored access token variable. These are the calls that will start returning HTTP 429 on October 19. Personal Access Tokens work across all API endpoints, while Job Tokens are scoped to CI-specific endpoints — check the docs for which endpoints each supports.

When you do hit a rate limit, GitLab returns a 429 response with Retry-After and RateLimit-ResetTime headers. Build backoff logic that reads the Retry-After header rather than hardcoding a wait interval. Note that some limits do not surface in response headers — your code can receive a 429 even when the previous response showed available quota remaining.

Related: GitHub Actions Self-Hosted Runners: Fix Before September 25

Use the Brownout Windows as a Test Run

GitLab is doing something genuinely developer-friendly with the brownout windows: two planned preview periods let you test the new limits before they are permanent. On October 7 and October 14, between 15:00 and 19:00 UTC, the new limits activate for Free and unauthenticated traffic, then revert. Four hours of real-world testing on each date, for free.

Use these windows intentionally. If your automation runs during those hours, check your logs for 429 errors. Better to discover a broken pipeline on October 7 than have production automation fail silently on October 20. If your scheduled tasks typically run outside that window, consider temporarily triggering them during the brownout to see how they behave under the new limits before committing to authentication changes.

Quick Audit Checklist

Before October 19, work through these steps against your GitLab.com integrations. The full GitLab announcement also includes a contact address — limits@gitlab.com — for teams with legitimately high-capacity needs:

• Search your codebase for gitlab.com/api/v4 without an accompanying PRIVATE-TOKEN, JOB-TOKEN, or Authorization: Bearer header
• Review .gitlab-ci.yml files for bare curl commands calling GitLab APIs without token variables
• Check monitoring and alerting scripts that poll GitLab endpoints on a schedule
• Verify third-party integrations and webhooks are authenticating properly
• Implement Retry-After header handling for 429 responses in all automation code
• If your authenticated Free-tier usage approaches 5,000 requests per hour, evaluate whether Premium is needed

Key Takeaways

• Unauthenticated GitLab.com API requests drop to 60 per hour on October 19 — any automation making unauthenticated calls will break
• The fix is free: add a Personal Access Token or use $CI_JOB_TOKEN in CI/CD jobs to get 5,000 requests per hour on the Free tier
• Use the brownout windows on October 7 and 14 (15:00-19:00 UTC) to identify problems before the permanent cutover
• Self-managed GitLab instances are not affected — only GitLab.com SaaS
• Premium and Ultimate limits do not apply until January 2027, but audit now while you have time