GitLab.com rate limits move to subscription tiers from October 19, 2026

GitLab will tie rate limits on GitLab.com to subscription tier, starting with Free accounts and unauthenticated requests on October 19, 2026. According to the company's announcement, which surfaced on the Hacker News front page, Premium and Ultimate plans move to their new limits in January 2027. The change applies only to the hosted GitLab.com service; Self-Managed and Dedicated instances keep whatever limits their operators set.

What is changing

Limits will be enforced per user and per top-level group, with each plan — Free, Premium and Ultimate — receiving its own ceiling, and the per-plan values published in GitLab's rate limits documentation. The headline number concerns anonymous traffic: requests arriving without credentials are capped at 60 requests per hour per IP address. GitLab stresses that this cap applies wherever the request originates, including automation running against a paid project without a token. Signed-in requests inherit the limits of the user's subscription plan.

GitLab frames the change as a response to growth, saying it expects platform load to multiply several times over this year, driven in part by the automation and agent workloads teams are building on the platform. The company says the ceilings were set by studying real usage and comparable platforms: nearly all users already operate inside the new limits, the Free and anonymous allowances match what rivals offer, and Premium and Ultimate limits sit at levels other platforms reserve for enterprise tiers or do not publish at all.

Brownouts before the switch

Two preview windows — brownouts, in engineering slang — will briefly enable the new Free and unauthenticated limits on October 7 and October 14, 2026, between 15:00 and 19:00 UTC. GitLab describes these as planned, reversible windows in which only the limits change, giving teams a realistic view of how their workloads behave weeks before enforcement begins. Signed-in Premium and Ultimate traffic is unaffected during the previews, since those limits do not change until January.

Who should worry

Per GitLab, a normal day looks the same for almost everyone: browsing the UI, editing, pushing and pulling over git, and running CI/CD within plan limits carry on unchanged. The workloads expected to hit the ceilings are heavy automation and some Free-tier projects. Public projects with heavy anonymous traffic get three options from the announcement's FAQ: have the calling automation authenticate so it uses its own plan's limits, make the project private to shut out anonymous callers entirely, or upgrade tiers.

How to prepare

The cheapest fix is authentication: a personal access token, OAuth token or CI/CD job token moves a request off the 60-per-hour anonymous allowance and onto the plan's much higher limits. Beyond that, GitLab recommends batching, caching and pagination, and warns that polling in a tight loop drains an allowance quickly. When a limit is crossed, the API returns HTTP 429 with a Retry-After header, alongside RateLimit-* headers including RateLimit-Remaining, which shows how much of the current window is left — so clients that read their response headers and back off exponentially largely heal themselves.

Members of several top-level groups inherit the highest tier available to them, so belonging to an Ultimate group grants the Ultimate limit. GitLab is also preparing a way to purchase capacity above standard plan limits, with details promised later this year, and a product view showing usage against plan limits is likewise planned. The company adds that access to and export of your own data and repositories is unaffected, and teams with genuinely anonymous integrations — a public status badge is the example given — can contact [email protected].

Why it matters

Rate limits are becoming the negotiation point between hosted platforms and the automation layer built on top of them, and GitLab is explicit that agent and automation workloads are part of what is pushing load up. CI/CD jobs, bots and scrapers that call GitLab.com without credentials are the first to be squeezed, and 60 requests per hour is low enough to break naive polling loops overnight. The October 7 and 14 brownouts are the practical deadline: teams that instrument their clients to respect 429 responses and Retry-After headers beforehand should see no disruption, while unauthenticated Free-tier automation may start failing without warning once October 19 arrives.