Blog News Automation check-in and rate limit changes on
Published on December 17, 2020
2 min read

Automation check-in and rate limit changes on

GitLab is making some changes to our rate limits on starting in January 2021.

Blog fallback hero

As the end of the year approaches, now is a good time to check in on your custom automations with ahead of a few changes we're planning to make to rate limits in the New Year. On January 18, 2021, we will be adding additional rate limits on activity:

  1. Unauthenticated traffic will be limited to 500 requests per minute from a given IP address.
  2. Authenticated traffic depends on whether it is to our API or not:
    1. API traffic will be limited to 2,000 requests per minute for a given user.
    2. All other HTTP traffic will be limited to 1,000 requests per minute for a given user.
  3. All traffic will be limited to 2,000 requests per minute from a given IP address when not covered by one of the limits above.

We have this information recorded in our documentation under rate limits. These limits apply to all HTTP requests made to, which could be from:

  1. Web browsers, while using the site
  2. Editor extensions that integrate with the GitLab API
  3. Git clients (if using Git over HTTP)
  4. Custom automation

What do users need to do?

We expect the limits will only apply to automated traffic, rather than individual people using the site through a browser. This means that automation customers should handle rate-limit responses by using the headers we mention in the documentation.

When a request is blocked due to rate limiting, GitLab will return a status code of 429, along with a Retry-After header indicating the number of seconds remaining until the current limit expires.

If you have automation that does not currently process a 429 response, and you use heavily, we recommend updating it for this case.

Beyond this situation, the majority of users will not need to do anything. If we notice that your traffic exceeds these limits, we may try to contact you directly. If the traffic is unauthenticated, we may not be able to do so.

Why is GitLab doing this?

We are always looking to improve the stability and availability of

What will happen in future?

In the future we aim to refine these limits as the usage of changes, which may involve introducing more specific limits, or reducing the existing limits. If API clients ensure that they process the retry headers correctly, as above, then they can handle any changes in these limits gracefully.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert