GitLab.com and Self-Managed · rate limits · Checked October 28, 2026

GitLab: 429 "Retry later" — over a rate limit

When a request goes over a rate limit, GitLab answers 429 Too Many Requests. Wait before you send it again: the Retry-After header says how many seconds remain until the quota resets (GitLab: GitLab.com rate limits, checked October 28, 2026). GitLab enforces two kinds of limits, and they answer differently:

HTTP/1.1 429 Too Many Requests
Content-Type: text/plain
Retry-After: 30
RateLimit-Name: throttle_authenticated_api

Retry later

HTTP/1.1 429 Too Many Requests
RateLimit-Name: notes_create

{"message":{"error":"This endpoint has been requested too many times. Try again later."}}

The two kinds of limits

• Limits on all requests (Rack::Attack, at the HTTP layer): for example authenticated API requests for a user, or unauthenticated requests from an IP address. The body is plain text, Retry later by default; an administrator can replace it in the Admin area, Settings > Network, User and IP rate limits. These limits show in the RateLimit headers below (GitLab: user and IP rate limits).
• Limits on one action (application rate limits): for example creating issues, or creating notes on issues and merge requests. The body is JSON with "This endpoint has been requested too many times. Try again later." under message.error, RateLimit-Name names the limit, and Retry-After is the length of its window. These limits are not in the RateLimit headers, so a 429 can come even when the previous answer showed quota left (GitLab source: lib/api/helpers/rate_limiter.rb and lib/gitlab/application_rate_limiter.rb, read on October 28, 2026).

The headers

• On every answer from a limit of the first kind: RateLimit-Limit (the quota for each minute), RateLimit-Name (the throttle, such as throttle_authenticated_api), RateLimit-Observed (requests in the window), RateLimit-Remaining and RateLimit-Reset (Unix time when the quota resets). They show only the most restrictive of these limits.
• On a 429: also Retry-After, the seconds until the quota resets, and RateLimit-ResetTime, the same as a date and time. GitLab counts the seconds to the end of the current window, so a limit for each hour can ask you to wait up to an hour (GitLab source: lib/gitlab/rack_attack/request_throttle_data.rb).
• Not everywhere: on GitLab.com, the 429 answers of the Projects, Groups and Users APIs do not include these headers.

GitLab.com: the limits today

• Authenticated API requests for a user: 2,000 each minute.
• Unauthenticated requests from an IP address: 500 each minute. All traffic from an IP address: 2,000 each minute.
• Notes on issues and merge requests: 60 each minute. Pipeline creation for a project, user or commit: 25 each minute.
• API requests to /api/v4/users/:id: 300 every 10 minutes. Search APIs: 100 each minute.

GitLab has also proposed limits by plan, not in effect yet and announced in advance, with brownout windows before they are enforced: for a user, 5,000 authenticated requests each hour on Free, 15,000 on Premium and 25,000 on Ultimate, with burst limits each minute (100 for API traffic on Free); and 60 unauthenticated requests each hour from an IP address. When both apply, the lower limit wins.

GitLab Self-Managed

The user and IP rate limits for API and web requests, authenticated or not, are off by default; an administrator turns them on and sets them in the Admin area, Settings > Network, User and IP rate limits. The note creation limit is on by default at 300 requests each minute for a user, with a list of users to exclude (note creation).

What to do

• Wait for Retry-After before you retry, and back off further if GitLab keeps answering 429.
• Use a token: requests without one get the lowest allowance, and are counted by IP address, together with the other requests from that address.
• Send fewer requests: watch RateLimit-Remaining, cache answers, page through lists instead of reading everything again, and slow down scripts that poll.
• On your own instance: an administrator can raise a limit, or exclude a user from the note creation limit.

GitLab merge requests and pipelines in IntelliJ IDEA

Lesstep makes two plugins for JetBrains IDEs 2024.1 or later: Merge Request Inbox for GitLab and Pipeline Inbox for GitLab CI. When GitLab answers 429, they say that the request limit of GitLab was reached and to wait a minute, then refresh; from Merge Request Inbox 1.0.19 and Pipeline Inbox 1.0.21, when Retry-After asks for longer than a minute, they say the time it opens again instead. Without a token, they suggest adding a personal access token in their settings (reading stays free). Reading is free; approving, commenting and merging, or retrying, cancelling and running pipelines, are Pro (US$1.50 a month, with a 30-day trial).

GITLAB is a trademark of GitLab Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitLab Inc. or JetBrains.

More: GitLab 401 "invalid_token" · GitLab "insufficient_scope" · GitLab 404 "Project Not Found" · GitLab comment or thread refused (400, 403) · GitLab merge request list refused (400, 404) · GitLab pipeline or job refused (400, 403, 409, 429) · GitLab "compare_timeout": true (diff limits) · GitLab merge request plugins for IntelliJ IDEA, compared · GitLab pipelines in JetBrains IDEs, compared · 日本語