In recent months, we have observed that the frequency and intensity of requests made by users to the Projects, Groups, and Users APIs have increased significantly. This has resulted in an increased load on our servers, which has impacted the performance and stability of our platform for all users. To address this issue, we have decided to introduce rate limitations for all users.
In the coming months, we will introduce rate limitations to the Projects, Groups and Users API according to the following schedule:
Groups and Projects API
- Brownouts
- Feb 4, 2025: For 12 hours starting at 12:00 UTC
- Mar 4, 2025: For 24 hours starting at 12:00 UTC
- Permanent rollout
- Apr 2, 2025 at 12:00 UTC
Users API
- Brownouts
- Feb 24, 2025: For 12 hours starting at 15:00 UTC
- Feb 27, 2025: For 24 hours starting at 15:00 UTC
- Permanent rollout
- Mar 3, 2025 at 12:00 UTC
To protect our Dedicated and Self-managed customers from unexpected changes, we're implementing a careful rollout strategy for our new API rate limitations. We'll be using a feature flag that allows us to apply these limits exclusively to GitLab.com while keeping them disabled by default for Self-managed and Dedicated instances.
When upgrading to 18.0, these rate limits will be set to zero and the feature flag will be disabled by default, ensuring no disruption to your current workflows. This approach gives administrators complete control - you can choose to enable these limits at your convenience by toggling the feature flag and setting the appropriate rate limits for your installation. In GitLab 18.1, the feature flag will be removed. It means the rate limits you've defined before that (unlimited by default) will automatically be used, even if you didn't enable the feature flag.
From GitLab 18.3, new installations will have the default rate limits (see "Rate limitation details" below) applied.
What are the Projects, Groups, and Users APIs?
The Projects and Groups APIs provide information about GitLab projects and groups, including name, description, and other metadata. The Users API provides information about GitLab users. These APIs are widely used by our community, including researchers, developers, and integrators, to retrieve and analyze information about GitLab projects, groups and users. We value this usage and aim to support it as much as possible.
Rate limitation details
All users of the Projects, Groups, and Users APIs will be rate-limited. The limits per endpoint are as follows:
| Endpoint | Rate limit per user or IP |
|---|---|
| GET /api/v4/users/:id/followers | 100 requests per minute |
| GET /api/v4/users/:id/following | 100 requests per minute |
| GET /api/v4/users/:user_id/status | 240 requests per minute |
| GET /api/v4/users/:user_id/keys | 120 requests per minute |
| GET /api/v4/users/:id/keys/:key_id | 120 requests per minute |
| GET /api/v4/users/:id/gpg_keys | 120 requests per minute |
| GET /api/v4/users/:id/gpg_keys/:key_id | 120 requests per minute |
| GET /api/v4/users/:user_id/projects | 300 requests per minute |
| GET /api/v4/users/:user_id/contributed_projects | 100 requests per minute |
| GET /api/v4/users/:user_id/starred_projects | 100 requests per minute |
| GET /api/v4/projects | 2000 requests per 10 minutes |
| GET /api/v4/groups/:id/projects | 600 requests per minute |
| GET /api/v4/projects/:id | 400 requests per minute |
| GET /api/v4/groups | 200 requests per minute |
| GET /api/v4/groups/:id | 400 requests per minute |
We rate-limit based on user for authenticated requests and based on IP for unauthenticated requests. We use the same value for both IP and user. The stated limits have been selected based on average usage patterns and should provide sufficient headroom for most use cases.
If a user exceeds this limit, the user will receive a "429 Too Many Requests" response. On GitLab.com, this limit cannot be changed. Users of GitLab Self-managed instances have the same rate limitation set by default, but admins can change the rate limits as they see fit via the UI or the application settings API. They can also set the rate limit to zero, which acts as if there is no rate limitation at all.
We understand that this change may impact some of our users who rely on the Projects, Groups, and Users APIs, and we apologize for any inconvenience this may cause.
If you have any questions or concerns about this change, please leave feedback in this issue.
Note
This post has been updated recently. These are the changes that were made:
- Added detailed rollout strategy for Self-managed/Dedicated: Introduces a phased implementation with feature flags that initially apply limits only to GitLab.com, with zero rate limits by default for Self-managed/Dedicated in GitLab 18.0.
- Clarified version timeline: Added specifics about feature flag removal in GitLab 18.1 and default rate limits for new installations starting in 18.3.
