| stage | group | info | type |
|---|---|---|---|
none |
unassigned |
To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments |
reference, howto |
NOTE: Note: For GitLab.com, please 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. Whether malicious, apathetic, or 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.
- Issues rate limits.
- User and IP rate limits.
- Raw endpoints rate limits.
- Protected paths.
- Import/Export rate limits.
Introduced in GitLab 12.9.
There is a rate limit for downloading repository archives, which 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.
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.
This method of rate limiting is cumbersome, but has some advantages. It allows throttling of specific paths, and is also integrated into Git and container registry requests. See Rack Attack initializer.