GitLab compute minute

A GitLab compute minute is the unit GitLab uses to meter CI/CD jobs that run on the runners it hosts: one minute of job execution multiplied by a cost factor set by the runner's type and size, deducted from the namespace's monthly compute quota.

How it is calculated

GitLab's compute minutes documentation gives the formula directly: compute minutes are job duration / 60 * cost factor.

Duration is the job's running time, so time a job spends created or pending is not counted — queue time is not billed, but it is also not free in any sense that matters to the developer waiting on it.

The cost factor is where the numbers move. As of 2026-07-28 GitLab publishes these factors for its hosted runners:

Linux Arm64 tracks the x86-64 factors for small, medium and large; the rows marked Beta can move, so check the source before budgeting on them. Project visibility also applies a factor: public projects accepted into GitLab's Open Source Program run at 0.5, and public forks of those projects at 0.008. GitLab publishes no per-job round-up rule — as of 2026-07-28 its compute minutes documentation states only the formula above and never mentions rounding — while GitHub explicitly documents rounding each job up to a whole minute. That difference alone can make an equivalent pipeline meter differently on the two providers.

Quotas and exemptions

Quotas are per namespace and reset monthly: on the first day of the month, recorded usage returns to zero. As of 2026-07-28, GitLab documents 400 compute minutes per month for Free-tier namespaces and states that paid tiers receive a higher monthly quota; the current per-tier allocations are on GitLab's pricing page, and additional minutes can be purchased. Exceeding the quota triggers enforcement — new jobs are not run and running jobs may be terminated until more minutes are purchased or the next month begins (compute minutes FAQ, checked 2026-07-28).

The important exemption: only the runners GitLab hosts and manages consume compute minutes. Runners you register and operate yourself — project and group runners, and every runner on a self-managed GitLab instance — do not draw on the quota at all (compute minutes FAQ, checked 2026-07-28), which is why teams with heavy pipelines often move them to self-hosted runners and pay their cloud provider instead.

Why it matters

Compute minutes are not wall-clock minutes, and the multiplier is chosen job by job. Bumping one job from a small to an xlarge runner to shave a few minutes multiplies its metered usage sixfold, which the pipeline view never shows. On self-hosted runners the meter disappears but the cost does not — it just moves to a bill nobody reconciles against pipelines.

Either way the question is the same: which repositories, pipelines and repeated failures are consuming the time. That attribution is the subject of GitLab CI compute minutes and cost.

TrimCI estimates cost from synced pipeline-run durations at a per-minute rate you configure per organization. It never reads your GitLab usage or billing data — its endpoint allowlist contains no usage or billing endpoint — so its figures are an attribution model to compare against the quota, not a mirror of it. That also makes them the same shape whether the pipeline ran on a hosted runner or your own.