GitLab's New Rate Limits: What to Fix Before Oct 19

GitLab is rolling out tier-aware rate limits on GitLab.com, and the number that will actually hurt you is 60 unauthenticated requests per hour per IP address. If any script, webhook listener, or AI coding agent in your pipeline talks to GitLab's API without a token, it has until October 19, 2026 to stop doing that, and GitLab is giving you two dress rehearsals first.

The schedule, because it's tighter than it looks#

GitLab will preview the new limits on October 7 and October 14, 2026, from 15:00 to 19:00 UTC, flipping them on and back off during those four-hour windows. Full enforcement for unauthenticated traffic and Free-tier accounts begins October 19, 2026. Premium and Ultimate customers get a longer runway: their new limits don't enforce until January 2027, though the limits themselves are already published. GitLab has stated the driver is platform load growing several times over this year, pointing specifically at automation and agent workloads teams are building on top of the platform, not organic human traffic.

The actual numbers#

Per GitLab's documentation, the new sustained (per-hour) limits are:

Unauthenticated traffic today effectively rides on a much looser limit than 60/hour, so this is a real cliff, not a tightening around the edges. A CI job that calls the API a few dozen times without a token will sail past 60 in the first twenty minutes of a Monday morning.

What actually breaks at 60 requests an hour#

Nobody writes a script that intentionally hits GitLab's API 60 times an hour unauthenticated. It happens by accident, in a handful of recurring shapes:

• Webhook polling instead of listening. A script that checks GET /projects/:id/pipelines every 30 seconds to see if a build finished does 120 calls an hour by itself, before anything else runs.
• CI steps that shell out to curl without a token. A .gitlab-ci.yml step that hits https://gitlab.com/api/v4/... to look up a merge request or a release tag, written once by someone in a hurry, with no Authorization header because it "just worked" in testing.
• AI coding agents that poll for context. An agent tool that re-fetches a project's file tree, issue list, or pipeline status on every turn, unauthenticated, racks up requests fast when it's iterating.
• Shared runners or shared IPs. If several jobs or several people share an egress IP, GitLab counts requests per IP, so one quiet script can burn through the budget another team needed.

None of these fail today because the old unauthenticated ceiling was generous. After October 19, the first one past 60 gets an HTTP 429 Too Many Requests and whatever called it either retries into a worse backoff or just breaks silently.

Audit now, not on the 19th#

The fix for almost every case above is the same: stop calling the API without credentials. Grep your pipelines and scripts for naked API calls first.

# find unauthenticated-looking GitLab API calls in your repo
$ grep -rn "gitlab.com/api/v4" --include="*.sh" --include="*.yml" . \
  | grep -v "Authorization\|PRIVATE-TOKEN\|CI_JOB_TOKEN"

Then check whether a request is actually authenticated and see your remaining budget using the response headers GitLab returns on every call:

# authenticate with a personal access token and inspect the rate-limit headers
$ curl -sI --header "PRIVATE-TOKEN: <your-token>" \
  "https://gitlab.com/api/v4/projects/<id>/pipelines" \
  | grep -i ratelimit

Inside GitLab CI, the fix is usually one line: swap a manual token for the job's built-in CI_JOB_TOKEN, which authenticates automatically and isn't subject to the unauthenticated ceiling.

# .gitlab-ci.yml
check_pipeline_status:
  stage: notify
  script:
    - curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/pipelines/latest"

For polling scripts outside CI, the real fix is to stop polling. Register a webhook for the event you care about (pipeline status, merge request updates, push events) instead of asking the API every 30 seconds whether anything changed. For AI agents and automation tools that fetch the same project metadata repeatedly, cache the response for a few minutes and batch lookups instead of issuing one call per file or per question.

Use the preview windows on purpose#

Most teams will discover a broken script when it breaks in production on October 19. You don't have to be one of them. The October 7 and October 14 preview windows, 15:00-19:00 UTC, are GitLab deliberately giving you a sandbox with the real limits turned on. Point your staging pipelines and any suspect automation at GitLab during those four-hour windows and watch for 429 responses. That's cheaper than finding out during a release.

The decision, concretely#

• Does any script or CI step call GitLab's API without a token? Fix it before October 19; unauthenticated traffic is capped at 60 requests per hour starting then.
• Is a tool polling the API on an interval for status changes? Replace it with a webhook; polling is the single biggest way to exhaust the new limits.
• Are you on Free tier with multiple automations sharing one token or IP? Watch the 5,000/hour and 100/minute burst ceiling; it's generous for a person, tight for several bots.
• Are you Premium or Ultimate? You have until January 2027, but the limits (15,000 and 25,000 requests/hour) are already documented, so audit now while there's no deadline pressure.

The call we'd make#

Treat October 7 and October 14 as free fire drills, not noise to ignore. Grep your scripts for unauthenticated calls, swap them for CI_JOB_TOKEN or a personal access token, and replace any polling loop with a webhook before October 19. Teams comparing CI platforms more broadly, including whether to lean on GitLab CI vs Jenkins or stick with GitHub Actions against GitLab CI, should factor rate limits like these into the total cost of ownership, not just pricing pages. The teams that get burned here won't be the ones with heavy automation; they'll be the ones who assumed a quick unauthenticated curl command would keep working forever.