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 every 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.

Configuration options

You can set most rate limits in the Admin area. Some are available only through the API or the Rails console, and you set the GitLab Pages rate limits in a configuration file.

Admin area

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

• API rate limits
• Content creation rate limits
• Git operations rate limits
• GitLab Orbit rate limits
• Import and export rate limits
• Incident management rate limits
• Pipeline creation rate limits
• Protected paths
• Raw endpoints rate limits
• User and IP rate limits
• Webhook operations rate limits

API and Rails console

You can set these rate limits with the application settings API:

• Autocomplete users rate limit
• AI action (ai_action_api_rate_limit): 160 calls every 8 hours for each authenticated user. Applies to the GraphQL aiAction mutation.
• Create tag rate limit (tags_create_limit): 100 requests every 30 minutes for each project. Applies to the REST API endpoint for creating a tag, the GraphQL tagCreate mutation, tag creation in the UI, and the /tag quick action.
• CSV import rate limit (issuable_csv_import_limit): 20 imports every hour for each authenticated user. Applies to importing issues, work items, and requirements from CSV, in the UI and through the workItemsCsvImport GraphQL mutation. The limit is shared between them. Introduced in GitLab 19.6 with a flag named issuable_csv_import_rate_limit. Disabled by default. This setting is in beta and might be changed or removed without notice.
• Work item move and clone rate limit (work_item_move_limit): 30 requests every minute for each authenticated user. Applies to moving and cloning issues and work items in the UI, through the REST API endpoints for moving an issue and cloning an issue, through the issueMove and workItemBulkMove GraphQL mutations, through the /move and /clone quick actions, and through the Slack issue move command. The limit is shared between them. A bulk move counts as one request for each item, and a bulk move with more items than the limit is rejected. The child items moved with an issue also count as one request each. Moves and clones of a single issue that fail for other reasons also count. Introduced in GitLab 19.6 with a feature flag named work_item_move_rate_limit_enforce. Disabled by default. While the flag is disabled, requests over the limit are logged but not blocked. This setting is in beta and might be changed or removed without notice.
• Add child items rate limit (work_item_hierarchy_add_children_limit): 300 child items every minute for each authenticated user. Applies to adding child items from the parent work item or epic: the workItemHierarchyAddChildrenItems GraphQL mutation, childrenIds in the workItemUpdate GraphQL mutation, the /add_child quick action, and the REST API endpoints for assigning an issue to an epic and assigning a child epic. The limit is shared between them. Each child item in a request counts toward the limit, and if a request would exceed the limit, no child items are added. Does not apply when you set a parent from the child work item. Introduced in GitLab 19.6 with a feature flag named work_item_hierarchy_add_children_limits. Disabled by default. This setting is in beta and might be changed or removed without notice. While the feature flag is disabled, requests over the limit are logged but not blocked.
• Delete label rate limit (label_delete_limit): 120 requests every minute for each authenticated user. Applies to deleting project and group labels in the UI and to the REST API endpoints for deleting a project label and deleting a group label. The limit is shared between them. Introduced in GitLab 19.6 with a feature flag named label_delete_rate_limit. Disabled by default. While the flag is disabled, deletes over the limit are logged but not blocked. This setting is in beta and might be changed or removed without notice.
• Pages deployments query rate limit (pages_deployments_api_limit): 1,000 resolutions every minute for each authenticated user. Unauthenticated requests are limited to 1,000 resolutions every minute for each IP address. Applies to the GraphQL pagesDeployments field on Project and Namespace. Each resolution of the field counts once, so a query that returns deployments for 100 projects counts as 100. Introduced in GitLab 19.6 with a flag named pages_deployments_api_rate_limit. Disabled by default. While the flag is disabled, requests over the limit are logged but not blocked. This setting is in beta and might be changed or removed without notice.
• Issue, epic, and work item update rate limit (work_item_update_limit): 600 updates every minute for each authenticated user. Applies to updating issues, epics, and work items from their pages, boards, and quick actions in the UI, through the REST API endpoints for updating an issue, reordering an issue, issue time tracking, updating an epic, and assigning an issue or a child epic to an epic, and through the GraphQL mutations that update them, including updateIssue, workItemUpdate, updateEpic, the issueSet mutations, and issueMoveList. The limit is shared between them. A bulk edit counts as one update for each item, and a bulk edit with more items than the limit is rejected. Introduced in GitLab 19.6 with a feature flag named work_item_update_rate_limit. Disabled by default. While the feature flag is disabled, updates over the limit are logged but not blocked. This setting is in beta and might be changed or removed without notice.
• Epic board move rate limit (epic_move_list_limit): 200 moves every minute for each authenticated user. Applies to the epicMoveList GraphQL mutation, and each alias in a request counts. Introduced in GitLab 19.6 with a feature flag named epic_move_list_rate_limit. Disabled by default. While the flag is disabled, moves over the limit are logged but not blocked. This setting is in beta and might be changed or removed without notice.
• Cross-reference rate limit (cross_reference_checks_limit): 800 references every minute for each user. When you save a description or comment, GitLab adds a “mentioned in” note to each item it references. Each reference GitLab checks counts toward the limit. Commits do not count toward the limit. If the user is over the limit, the save succeeds, but GitLab adds no “mentioned in” notes for that save. Each save, including a pushed commit, checks at most 150 references. If a save has more references, GitLab checks work items and issues first, then merge requests, commits, and epics. Internal users and service accounts with composite identity have a separate limit for each project or group. Project and group access token users have a single limit, like other users. Introduced in GitLab 19.6 with a feature flag named enforce_cross_reference_limits. Disabled by default. This setting is in beta and might be changed or removed without notice.
• Retrieve file blame rate limit (project_repositories_blame_limit, project_repositories_blame_unauthenticated_limit): 400 requests every minute for each user and project. Unauthenticated requests are limited to 400 requests every minute for each IP address. Applies to the REST API endpoint for file blame and to the GraphQL blame field on RepositoryBlob, which the blame view in the UI uses.
• List repository commits rate limit (project_repository_commits_api_limit): 5,000 commits with stats every minute for each authenticated user, or for each IP address for unauthenticated requests. Applies to the REST API endpoint for listing repository commits when the with_stats or all parameter is used. A with_stats request counts as the number of commits returned, and a request that uses the all parameter counts as 3 more. Introduced in GitLab 19.6 with a feature flag named rate_limit_project_repository_commits_api. Disabled by default.
• List to-do items rate limit (todos_list_api_limit): 300 requests every minute for each authenticated user. Applies to the REST API endpoint for listing to-do items. Introduced in GitLab 19.6. This setting is in beta and might be changed or removed without notice.
• Protected branch write rate limit (protected_branch_write_limit): 5,000 requests every hour for each user in each top-level group or personal namespace. Applies when a user protects or unprotects a branch in the UI, with the project or group REST API, or with the branchRuleCreate and branchRuleDelete GraphQL mutations. Protect and unprotect actions share the limit. Changes to an existing protected branch do not count against the limit. Introduced in GitLab 19.6 with a feature flag named protected_branch_write_rate_limit_enforce. Disabled by default. While the flag is disabled, GitLab counts requests over the limit but does not reject them. This setting is in beta and might be changed or removed without notice.
• Read wiki pages rate limit (wiki_read_request_limit_unauthenticated): 500 requests every minute for each project or group wiki, shared by all unauthenticated users. Applies to wiki pages in the UI and to the REST API endpoints that list and retrieve project and group wiki pages. Introduced in GitLab 19.6 with a feature flag named wiki_read_unauthenticated_rate_limit_enforce. Disabled by default. This setting is in beta and might be changed or removed without notice.
• GitLab Credits usage rate limit (subscription_usage_per_minute_limit, subscription_usage_per_hour_limit, subscription_usage_per_day_limit): 300 requests every minute, 10,000 every hour, and 40,000 every day for each authenticated user. Applies to the GraphQL subscriptionUsage and trialUsage fields, which share one limit. Introduced in GitLab 19.6 with a feature flag named enforce_subscription_usage_rate_limits. Disabled by default.
• GitLab Credits budget cap rate limit (budget_cap_update_per_minute_limit, budget_cap_update_per_hour_limit, budget_cap_update_per_day_limit): 150 mutation calls every minute, 1,000 every hour, and 20,000 every day for each authenticated user. Applies to the GraphQL upsertUserBudgetCapOverrides and upsertFlatUserCap mutations, which share one limit. Introduced in GitLab 19.6 with a feature flag named enforce_budget_cap_rate_limits. Disabled by default.
• Rebase merge request rate limit (merge_requests_rebase_limit): 30 requests every minute for each authenticated user. Applies to the REST API endpoint for rebasing a merge request, rebasing from the UI, and the /rebase quick action. The limit is shared between them. Introduced in GitLab 19.6 with a feature flag named merge_requests_rebase_rate_limit. Disabled by default. This setting is in beta and might be changed or removed without notice.

You can set this rate limit with the plan limits API or the Rails console:

• Webhook rate limit

Configuration file

You can set these rate limits only in the configuration file for your installation, for example /etc/gitlab/gitlab.rb in a Linux package installation:

• GitLab Pages rate limits

Non-configurable limits

Some rate limits cannot be configured. For a list of these limits, see non-configurable rate limits.

Bans and blocks

Some protections block a client for a period of time instead of slowing requests down. For more information, see abuse and failed authentication bans.

Related topics

• GitLab application limits
• CI/CD limits