Summary

  • GitLab.com hosted build jobs consume a top-level namespace's allowance. Separate projects and subgroups can therefore depend on the same remaining balance.
  • Purchased compute minutes supplement the included quota and unused packs roll forward, but they cannot be transferred between groups. Their stated twelve-month validity is not a promise of perpetual availability, even though expiry is currently unenforced.
  • Allowance exhaustion, runner availability and safe permission to execute are different conditions. A sound purchasing decision accounts for all three without treating fewer tests or weaker isolation as savings.

An organisational chart with a meter attached

Two teams can manage different projects, maintain different release calendars and report to different budget owners while sharing one GitLab.com compute allowance. Imagine a product project and an internal-tools project placed beneath the same top-level group. Neither team changes the other's code. Yet one team's hosted build activity reduces the allowance available to the other.

This is an illustrative arrangement, not a reported customer incident. It reveals a choice that can be made almost accidentally when software work is organised: where should a common resource pool begin and end? A group structure that makes collaboration convenient also helps determine which workloads share a commercial stopping point.

GitLab's compute-minute documentation assigns job usage to the top-level namespace of the project in which the job runs. It is not charged to a contributor's personal namespace merely because that person pressed the button. The namespace model allows groups to contain subgroups with their own settings. That administrative distinction does not create a separate top-level allowance for every subgroup.

Pooling has a sensible purpose. A quiet project's unused headroom can accommodate another project's busy period without a separate purchase. But pooling also makes the timing of demand a shared concern. Separate project ownership is not the same as an isolated budget. The buyer must decide whether the people allowed to consume the pool are working under a common understanding of its priorities.

Minutes that do not measure the same thing

The name of the unit invites a misleading comparison. A developer sees how long a pipeline took to finish. The allowance records weighted execution across the jobs that ran. Under the documented formula, a job's duration in seconds is divided by sixty and multiplied by a cost factor; created and pending time are excluded.

As a deliberately simplified example, three independent ten-minute jobs running concurrently at a factor of one use thirty compute minutes, even if their execution overlaps within a ten-minute interval. That arithmetic assumes no additional jobs or overhead. It is not a performance benchmark or a forecast of a customer's bill.

Faster feedback can be worth that consumption. It can also be obtained by removing duplicated work rather than adding parallel machines. The pipeline-efficiency guide distinguishes the critical path, dependencies, machine sizing and preparation work. A shorter critical path and a smaller quota debit are separate achievements; one does not prove the other.

For a shared group, the useful question is therefore not which team produces the shortest pipelines. It is which changes improve the value of the work performed relative to the common allowance. A project with longer but necessary tests should not automatically lose out to a project whose dashboard looks quicker because it tests less.

Exhaustion is a defined sequence

The group boundary becomes most visible when the allowance is depleted. GitLab's quota-enforcement rules provide warnings below twenty-five per cent, below five per cent and at zero remaining. Namespace owners receive email notifications, and an in-app banner is displayed. The recipient of the warning need not be the person deciding how many jobs another project starts.

Once the applicable allowance is exhausted, instance runners stop processing new jobs. Pending or retried jobs requiring those runners in already-started pipelines are dropped. Running jobs can continue until aggregate namespace usage exceeds the quota by one thousand compute minutes; beyond that grace boundary, remaining running jobs are also dropped. Project and group runners are unaffected by this particular quota.

The one-thousand-minute figure is not a reserve awarded to every project. Nor is it a guarantee that a running pipeline will finish. Several workloads can be consuming the same aggregate margin. Treating it as a dependable emergency budget would misunderstand both its scope and its purpose.

None of this establishes a GitLab outage. The service can be behaving as documented while a customer's work cannot proceed on the affected runners. That distinction changes the remedy. An infrastructure incident calls for service recovery; a depleted allowance calls for an authorised purchasing or workload decision. Confusing the two can send an urgent problem to somebody who lacks the power to resolve it.

Money on the other side of the group boundary

Buying an additional pack is not the same as increasing the recurring monthly allocation. GitLab's purchasing documentation says additional minutes are used after the included quota. Unused purchased minutes carry forward, but the pack is a one-time purchase rather than a fresh entitlement every month.

The important spatial rule is that purchased minutes cannot be transferred between groups. A company may therefore have an unused pack attached to one group and a need for more allowance in another. That is a possibility created by the stated rule, not evidence that a named company has stranded spending. A consolidated internal spreadsheet cannot itself move the entitlement.

Time adds another qualification. Purchased minutes have a stated validity of twelve months from purchase. Expiry is not currently enforced, but GitLab does not guarantee their validity after that date. A balance still visible after twelve months is consequently different from a guaranteed permanent reserve. Subscription-tier changes, by contrast, leave the purchased minutes available, including a move to Free.

These distinctions reward accurate purchasing records: the receiving group, purchase date, included allocation and remaining additional balance. They do not justify reorganising repositories solely to chase a cheaper-looking total. Access, collaboration and operational dependencies also follow project organisation, and this evidence does not establish every consequence of a project transfer.

An allowance is not a reservation

Even an adequately funded group needs a suitable runner. GitLab's runner overview describes matching according to tags, scope, status, capacity and capabilities. Purchase authority does not override those conditions.

The hosted-runner documentation gives a start-time objective: ninety per cent of jobs should begin execution within 120 seconds. That is an SLO, not a statement that the objective was achieved during a particular month, and not a reservation for a buyer's next job. A normal GitLab.com hosted job receives a fresh virtual machine; the special community-contribution arrangements have different characteristics.

The buyer is dealing with three questions, then: is there allowance, is a compatible execution environment available, and is this work authorised to run there? A positive answer to one cannot stand in for the others. More minutes may address a quota constraint without improving a mismatched job configuration or a waiting-time problem.

Project analytics can help maintain that distinction. GitLab's CI/CD analytics exposes pipeline duration and outcome measures. Those describe the work's behaviour, while the namespace meter describes a common consumption boundary. Neither view alone establishes that the organisation is getting the right tests at the right time.

Changing the payer can change the trust decision

Forked work makes the boundary particularly tangible. A merge request from a fork normally runs its pipeline in that fork and uses its resources. An appropriately permitted member can instead start the pipeline in the parent project, using the fork branch's configuration with the parent's execution context and resources. GitLab's merge-request pipeline guidance explicitly warns about reviewing untrusted code before doing so.

The move is not merely a way to find an allowance with minutes left. It changes whose resources support the work and under whose permissions it runs. Protected variables and runners also retain their own restrictions; the documentation does not say that every parent-project run gains access to every secret.

A similar distinction applies to customer-managed runners. A project or group runner can keep processing outside the instance-runner quota, but the customer takes responsibility for its operating environment. GitLab's security guidance discusses the risks of shared, non-ephemeral execution. Avoiding one consumption meter does not make host maintenance, isolation or capacity management disappear.

The evidence supports a narrower, more useful purchasing conclusion than “hosted builds are expensive”. Group structure determines which work shares the allowance and where purchased headroom can be used. The company should choose that structure consciously, with a replenishment decision that reaches the relevant owner before scarcity starts making the decisions instead.

Sources and scope

The analysis uses the current GitLab documentation reviewed on 3 September 2026: compute minutes, quota enforcement, additional purchases and namespaces.

Operational distinctions come from pipeline efficiency, runners, hosted runners, merge-request pipelines, self-managed security and CI/CD analytics. No customer invoice, private telemetry or negotiated contract was inspected. The quota analysis concerns GitLab.com, not an assertion that every Self-Managed or Dedicated installation follows the same commercial arrangement.