On September 17, 2026 GitLab announced that gitlab.com is moving to rate limits tied to your subscription plan, applied per user and per top-level group. The announcement sets the dates; the rate limits documentation carries the actual numbers. This affects gitlab.com only. Self-managed and Dedicated instances set their own limits and are not part of this change.
The 60-second version
- Free and unauthenticated limits are enforced from October 19, 2026; Premium and Ultimate follow in January 2027.
- Unauthenticated requests get 60 per hour per IP. Authenticate everything you can.
- Authenticated sustained limits per user: Free 5,000/hour, Premium 15,000/hour, Ultimate 25,000/hour.
- Short burst limits per minute: Free 100, Premium 1,250, Ultimate 2,000.
- Limits are scoped per user and per top-level group, and apply to gitlab.com only.
1. What is actually changing
Today gitlab.com applies flat request limits that are the same regardless of your plan. The new scheme replaces that with two tiers of limit per subscription: a sustained hourly limit and a shorter per-minute burst limit, both measured per authenticated user and per top-level group. The published figures in the rate limits documentation are:
- Free: 5,000 requests per hour, bursting to 100 per minute.
- Premium: 15,000 requests per hour, bursting to 1,250 per minute.
- Ultimate: 25,000 requests per hour, bursting to 2,000 per minute.
- Unauthenticated: 60 requests per hour, per IP address, on every plan.
GitLab notes that sustaining the per-minute burst for a full hour would blow past the hourly limit on every plan, so treat the burst number as headroom for spikes, not a rate you can hold.
2. The dates that matter
The rollout is staged, and the announcement spells it out:
- October 7 and October 14, 2026, 15:00 to 19:00 UTC: preview windows where the Free and unauthenticated limits are switched on temporarily, so you can see whether you would be throttled.
- October 19, 2026: Free and unauthenticated limits take effect for good.
- January 2027: Premium and Ultimate limits take effect.
The two October preview windows are the useful part. If a job or an integration starts erroring during those four hours, that is your dress rehearsal for October 19.
3. Why this matters for Slack notifications and API tools
The number that catches most people is 60 requests per hour for unauthenticated traffic. Any tool hitting the gitlab.com API without a token, a status page, a homegrown script, a webhook receiver that turns around and calls back into the API, shares that 60/hour with every other unauthenticated caller on the same IP. That is not enough for anything real.
Tools that post MR activity to Slack are the obvious case. If your notifier polls the API on a timer to check MR state or pipeline status, every poll counts against the limit, and it counts against the token owner's per-user budget. A tight polling loop across a busy group can eat a Free plan's 5,000/hour faster than you would guess. The fix is the same one that makes for a better integration anyway: prefer webhooks, which push events to you, over polling that asks the API the same question every 30 seconds. GitLab's own ways to connect GitLab to Slack lean on webhooks for exactly this reason.
Full disclosure: we make PRFlow, a GitLab-to-Slack notifier. It is webhook-driven, so it reacts to events GitLab sends rather than polling the API on a timer, which keeps its request footprint low under limits like these. If you are auditing what talks to your GitLab, our GitLab integration page lists exactly which scopes it uses.
4. What to do before October 19
- Authenticate every request. Moving off the 60/hour anonymous bucket and onto your plan's budget is the single biggest win. Use a token, and know which user and plan it bills to.
- Swap polling for webhooks wherever you can. A webhook that fires on an event costs you nothing against the API limit; a poll every minute costs you 60 requests an hour before you have done any real work.
- Watch the RateLimit response headers. GitLab returns them so a client can back off before it hits the ceiling. The rate limits docs are the reference for the exact header names and reset behavior.
- Use the October preview windows. Run your normal load during the October 7 and October 14 brownouts and see what breaks while it is still reversible.
5. Self-managed teams: mostly a non-event
This announcement is about gitlab.com. If you run self-managed or Dedicated GitLab, your instance sets its own request limits, and this change does not touch them. It is still worth a look at how your own instance is configured, especially if you have integrations that poll it, but the October and January dates are not yours to worry about. For that setup the practical guidance is the same as always: see self-hosted GitLab Slack notifications for the webhook-first approach.
Bottom line
If you are on gitlab.com, spend ten minutes before October 19 confirming that everything touching the API sends a token, and that nothing important is polling when it could be listening for a webhook. The preview windows on October 7 and October 14 will tell you the truth for free. That is where the surprises will show up.