Rate limits

DETAILS: Tier: Free, Premium, Ultimate Offering: Self-managed, GitLab Dedicated

NOTE: For GitLab.com, see GitLab.com-specific rate limits.

Rate limiting is a common technique used to improve the security and durability of a web application.

For example, a simple script can make thousands of web requests per second. The requests could be:

• Malicious.
• Apathetic.
• Just a bug.

Your application and infrastructure may not be able to cope with the load. For more details, see Denial-of-service attack. Most cases can be mitigated by limiting the rate of requests from a single IP address.

Most brute-force attacks are similarly mitigated by a rate limit.

NOTE: The rate limits for API requests do not affect requests made by the frontend, because these requests are always counted as web traffic.

Configurable limits

You can set these rate limits in the Admin Area of your instance:

• Import/Export rate limits
• Issue rate limits
• Note rate limits
• Protected paths
• Raw endpoints rate limits
• User and IP rate limits
• Package registry rate limits
• Git LFS rate limits
• Rate limits on Git SSH operations
• Files API rate limits
• Deprecated API rate limits
• GitLab Pages rate limits
• Pipeline rate limits
• Incident management rate limits
• Projects API rate limits
• Groups API rate limits

You can set these rate limits using the Rails console:

• Webhook rate limit

Failed authentication ban for Git and container registry

GitLab returns HTTP status code 403 for 1 hour, if 30 failed authentication requests were received in a 3-minute period from a single IP address. This applies only to combined:

• Git requests.
• Container registry (/jwt/auth) requests.

This limit:

• Is reset by requests that authenticate successfully. For example, 29 failed authentication requests followed by 1 successful request, followed by 29 more failed authentication requests would not trigger a ban.
• Does not apply to JWT requests authenticated by gitlab-ci-token.
• Is disabled by default.

No response headers are provided.

To avoid being rate limited, you can:

• Stagger the execution of your automated pipelines.
• Configure exponential back off and retry for failed authentication attempts.
• Use a documented process and best practice to manage token expiry.

For configuration information, see Omnibus GitLab configuration options.

Non-configurable limits

• Rate limit on the :user_id/status, :id/following, :id/followers, :user_id/keys, id/keys/:key_id, :id/gpg_keys, and :id/gpg_keys/:key_id endpoints introduced in GitLab 17.1 with a flag named rate_limiting_user_endpoints. Disabled by default.

FLAG: The availability of multiple endpoints in this feature is controlled by a feature flag. For more information, see the history. These endpoints are available for testing, but not ready for production use.

Repository archives

A rate limit for downloading repository archives is available. The limit applies to the project and to the user initiating the download either through the UI or the API.

The rate limit is 5 requests per minute per user.

Webhook Testing

There is a rate limit for testing webhooks, which prevents abuse of the webhook functionality.

The rate limit is 5 requests per minute per user.

Users sign up

There is a rate limit per IP address on the /users/sign_up endpoint. This is to mitigate attempts to misuse the endpoint. For example, to mass discover usernames or email addresses in use.

The rate limit is 20 calls per minute per IP address.

User status

There is a rate limit per IP address on the :user_id/status endpoint. This is to mitigate attempts to misuse the endpoint.

The rate limit is 240 calls per minute per IP address.

User following

There is a rate limit per IP address on the :id/following endpoint. This is to mitigate attempts to misuse the endpoint.

The rate limit is 100 calls per minute per IP address.

User followers

There is a rate limit per IP address on the :id/followers endpoint. This is to mitigate attempts to misuse the endpoint.

The rate limit is 100 calls per minute per IP address.

User keys

There is a rate limit per IP address on the :user_id/keys endpoint. This is to mitigate attempts to misuse the endpoint.

The rate limit is 120 calls per minute per IP address.

User specific key

There is a rate limit per IP address on the id/keys/:key_id endpoint. This is to mitigate attempts to misuse the endpoint.

The rate limit is 120 calls per minute per IP address.

User GPG keys

There is a rate limit per IP address on the :id/gpg_keys endpoint. This is to mitigate attempts to misuse the endpoint.

The rate limit is 120 calls per minute per IP address.

User specific GPG keys

There is a rate limit per IP address on the :id/gpg_keys/:key_id endpoint. This is to mitigate attempts to misuse the endpoint.

The rate limit is 120 calls per minute per IP address.

Update username

There is a rate limit on how frequently a username can be changed. This is enforced to mitigate misuse of the feature. For example, to mass discover which usernames are in use.

The rate limit is 10 calls per minute per authenticated user.

Username exists

There is a rate limit for the internal endpoint /users/:username/exists, used upon sign up to check if a chosen username has already been taken. This is to mitigate the risk of misuses, such as mass discovery of usernames in use.

The rate limit is 20 calls per minute per IP address.

Project Jobs API endpoint

• Introduced in GitLab 15.7 with a flag named ci_enforce_rate_limits_jobs_api. Disabled by default.
• Generally available in GitLab 16.0. Feature flag ci_enforce_rate_limits_jobs_api removed.

There is a rate limit for the endpoint project/:id/jobs, which is enforced to reduce timeouts when retrieving jobs.

The rate limit defaults to 600 calls per authenticated user. You can configure the rate limit.

AI action

• Introduced in GitLab 16.0.

There is a rate limit for the GraphQL aiAction mutation, which is enforced to prevent from abusing this endpoint.

The rate limit is 160 calls per 8 hours per authenticated user.

Delete a member using the API

• Introduced in GitLab 16.0.

There is a rate limit for removing project or group members using the API endpoints /groups/:id/members or /project/:id/members.

The rate limit is 60 deletions per minute.

Notification emails

• Introduced in GitLab 17.1 with a flag named rate_limit_notification_emails. Disabled by default.

FLAG: The availability of this feature is controlled by a feature flag. For more information, see the history. This feature is available for testing, but not ready for production use.

There is a rate limit for notification emails related to a project or group.

The rate limit is 1,000 notifications per 24 hours per project or group per user.

Troubleshooting

Rack Attack is denylisting the load balancer

Rack Attack may block your load balancer if all traffic appears to come from the load balancer. In that case, you must:

1. Configure nginx[real_ip_trusted_addresses]. This keeps users' IPs from being listed as the load balancer IPs.

2. Allowlist the load balancer's IP addresses.

3. Reconfigure GitLab:

   sudo gitlab-ctl reconfigure

Remove blocked IPs from Rack Attack with Redis

To remove a blocked IP:

1. Find the IPs that have been blocked in the production log:

   grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log

2. Since the denylist is stored in Redis, you must open up redis-cli:

   /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket

3. You can remove the block using the following syntax, replacing <ip> with the actual IP that is denylisted:

   del cache:gitlab:rack::attack:allow2ban:ban:<ip>

4. Confirm that the key with the IP no longer shows up:

   keys *rack::attack*

   By default, the keys command is disabled.

5. Optionally, add the IP to the allowlist to prevent it being denylisted again.