Rate limits

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.

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
• Unauthenticated access to Projects List 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.

For configuration information, see Omnibus GitLab configuration options .

Non-configurable limits

Repository archives

Introduced in GitLab 12.9.

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

Introduced in GitLab 13.4.

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

Introduced in GitLab 14.7.

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.

Update username

Introduced in GitLab 14.7.

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

Introduced in GitLab 14.7.

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

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

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

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.

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:

Configure nginx[real_ip_trusted_addresses] . This keeps users’ IPs from being listed as the load balancer IPs.
1. Allowlist the load balancer’s IP addresses.

2. Reconfigure GitLab:

   sudo gitlab-ctl reconfigure
   

Remove blocked IPs from Rack Attack with Redis

To remove a blocked IP:

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

grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
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
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>
Confirm that the key with the IP no longer shows up:

keys *rack::attack*

By default, the keys command is disabled .

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

Help & feedback

Docs

Edit this page to fix an error or add an improvement in a merge request.
Create an issue to suggest an improvement to this page.

Product

Create an issue if there's something you don't like about this feature.
Propose functionality by submitting a feature request.
Join First Look to help shape new features.

Feature availability and product trials

View pricing to see all GitLab tiers and features, or to upgrade.
Try GitLab for free with access to all features for 30 days.

Get Help

If you didn't find what you were looking for, search the docs .
If you want help with something specific and could use community support, post on the GitLab forum .
For problems setting up or using this feature (depending on your GitLab subscription).

Request support