Quotas
Overview
Every organization has limits on how much it can create and keep — repositories per group, members per group or repository, open merge requests per repository, webhooks, access tokens, stored bytes, pipeline minutes. The numbers come from your plan, and a request that would pass one is refused with 429 and creates nothing.
Limits are soft: one can be raised for one organization without changing plan, up to a hard ceiling no request passes.
How it works
What is counted, and where
Most limits are a cap on a count, held on the thing that contains what you create. A few are pooled across the whole organization — the top-level group and everything beneath it.
| Limit | Counted per | Free plan |
|---|---|---|
| Repositories | group | 20 |
| Members | group or repository | 50 |
| Open merge requests | repository | 100 |
| Webhooks | group or repository | 20 |
| Service accounts | group or repository | 10 |
| Access tokens | person or service account | 100, on every plan |
| Stored bytes | organization | 5 GiB |
| Pipeline runs and minutes | organization, per calendar month | 500 runs, 2,000 minutes |
There are caps on smaller things too — comments on one merge request, reviewers, reactions on a comment, statuses on a commit, criteria on a work item — so nothing a client can repeat in a loop grows without bound. Billing lists every plan's values.
Reads never consume a quota. Writes that create, reopen, move in or start something counted do — reopening a merge request counts against open merge requests, moving a work item into a repository against that repository's open work items, starting a pipeline against the month's runs — while edits and deletes do not. Outbound bytes are a separate budget, measured over time rather than as a count: see Egress.
Reaching a cap
The request that would pass the cap answers 429 TOO_MANY_REQUESTS. Nothing is created, stored or started, and no counter moves, so the same request sent again gets the same answer. Deleting something frees its place straight away, and the next create succeeds.
The one size limit that answers differently is an avatar: an image over 5 MiB is refused with 400 BAD_REQUEST before an upload address is issued.
Enforced and deferred
The API reference marks each operation that creates something with the limit it counts against:
- Quota, naming the limit — the cap is charged on every call, and reaching it answers
429. - Quota (deferred) — the operation creates something the plan puts a number on, and the cap is agreed but not charged: the operation is not refused when the count passes that number. Branches per repository and tags per repository are the two deferred caps.
An operation with neither marking adds nothing that is counted — an update in place, a delete, a toggle.
Plans, overrides and ceilings
There are four plans — Free, Pro, Team and Enterprise — and each raises every limit or holds it level. The limit enforced for your organization is its override if it has one, otherwise the plan's value, and never more than the ceiling for that limit.
Settings → Usage on any group shows each limit at the value actually enforced, with current usage beside it where it can be counted. Reporter on the group is enough to read it.
Asking for more
An Owner of the top-level group can file a limit-increase request naming one limit, the value wanted and why. It is reviewed by Gitmoap, and an approval applies to the very next check. A request records the person who filed it, so it needs a personal token rather than a service account's, and one request per limit can be open at a time — a second answers 409 CONFLICT.
The number of top-level groups you may own belongs to you rather than to an organization: it starts at 3, and an approved request raises your own budget.