THE USEFUL BIT

GitLab Will Change Rate Limits on October 19: What Developers Need to Know

GitLab.com is preparing to introduce subscription-based request limits on October 19, 2026. Before the change goes live, GitLab scheduled short preview windows to help developers see whether their scripts, API integrations or other automated workloads could be affected.

The second preview window was scheduled for October 14, from 15:00 to 19:00 UTC — 17:00 to 21:00 in Rwanda. GitLab describes these temporary tests as a way to expose possible problems before the permanent rollout.

What is changing?

GitLab announced on September 17 that it plans to introduce subscription-based request limits on GitLab.com. The first phase affects Free accounts and unauthenticated requests on October 19. Premium and Ultimate plan changes are scheduled for January 2027.

One of the clearest changes affects requests that do not include authentication. Under the planned rules, unauthenticated traffic is limited to 60 requests per hour per IP address. GitLab's proposed Free-tier limits also include a sustained allowance of 5,000 requests per hour per authenticated user, with a separate burst ceiling of 100 requests per minute. The hourly sustained limit still matters for ongoing traffic, and developers should check the current documentation rather than assume every endpoint is governed identically.

Will normal Git pushes or deployments stop working?

Not automatically. GitLab says ordinary signed-in work — including browsing the site, using the editor, pushing and pulling repositories, and running CI/CD within the applicable plan limits — should continue as usual. The greater risk is for heavy automation, frequent polling, or scripts that call GitLab without credentials. Workloads that exceed a limit may receive an HTTP 429 Too Many Requests response.

If your automation relies on the GitLab API, review whether requests are authenticated. GitLab recommends authenticating eligible requests, reducing unnecessary calls, caching results, batching or paginating where appropriate, and respecting the Retry-After response header before retrying a throttled request.

What developers should do now

  • Check the official GitLab rate-limit documentation for the plan limits that apply to your workload.
  • Review scripts, bots and CI/CD jobs that repeatedly call the GitLab API, particularly those that do not send authentication credentials.
  • Monitor rate-limit response headers and handle 429 responses with a wait-and-retry strategy instead of retrying continuously.
  • If you use GitLab Self-Managed or GitLab Dedicated rather than GitLab.com, note that this announced change does not apply to those hosted offerings; their limits are controlled separately.

The bottom line: Most everyday users may notice no difference, but developers running frequent or anonymous automated requests should check their usage before October 19. The preview window is an opportunity to find potential issues early — not an announcement that GitLab is shutting down normal Git pushes or deployments.

Sources

✳
Keep your curiosity going.

Good information should help you ask better questions, not stop asking them.

FILED UNDERGitLabGitLab rate limitsGitLab.comdevelopersAPI limitsCI/CDDevOpssoftware developmenttechnology news