Compute minutes

{{< details >}}

• Tier: Free, Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

{{< history >}}

• Renamed from "CI/CD minutes" to "compute quota" or "compute minutes" in GitLab 16.1.

{{< /history >}}

The usage of instance runners by projects running CI/CD jobs is measured in compute minutes.

For some installation types, your namespace has a compute quota, which limits the available compute minutes you can use.

A compute quota can be applied to all admin-managed instance runners:

• All instance runners on GitLab.com or GitLab Self-Managed
• All self-hosted instance runners on GitLab Dedicated

The compute quota is disabled by default but can be enabled for top-level groups and user namespaces. On GitLab.com, the quota is enabled by default to limit usage on Free namespaces. The limit is increased if a paid subscription is purchased.

GitLab-hosted instance runners on GitLab Dedicated cannot have the instance runner compute quota applied.

Instance runners

For instance runners on GitLab.com, GitLab Self-Managed, and self-hosted instance runners on GitLab Dedicated:

• You can view your usage in the instance runner usage dashboard.
• When a quota is enabled:
  • You receive notifications when approaching your quota limits.
  • Enforcement measures are applied when you exceed your quota.

For GitLab.com:

• The base monthly compute quota is determined by your subscription tier.
• You can purchase additional compute minutes if you need more.

Compute minute usage

Compute usage calculation

Your compute minute usage for each job is calculated using this formula:

Job duration / 60 * Cost factor

• Job duration: The time, in seconds, that a job took to run, not including time spent in the created or pending statuses.
• Cost factor: A number based on the runner type and project type.

The value is converted into compute minutes and added to the count of used units in the job's top-level namespace.

For example, if a user alice runs a pipeline:

• In a project in the gitlab-org namespace, the compute minutes used by each job in the pipeline are added to the overall usage for the gitlab-org namespace, not the alice namespace.
• In a personal project in their alice namespace, the compute minutes are added to the overall usage for their namespace.

The compute used by one pipeline is the total compute minutes used by all the jobs that ran in the pipeline. Jobs can run concurrently, so the total compute usage can be higher than the end-to-end duration of a pipeline.

Trigger jobs do not execute on runners, so they do not consume compute minutes, even when using strategy:depend to wait for the downstream pipeline status. The triggered downstream pipeline consumes compute minutes the same as other pipelines.

Usage is tracked on a monthly basis. On the first day of the month the usage is 0 for that month for all namespaces.

Cost factors

The rate at which compute minutes are consumed varies based on the runner type and project settings.

Cost factors of hosted runners for GitLab.com

GitLab-hosted runners have different cost factors depending on the runner type (Linux, Windows, macOS) and the virtual machine configuration:

These cost factors apply to hosted runners for GitLab.com.

Certain discounts apply based on the project type:

Community contributions to GitLab projects

Community contributors can use up to 300,000 minutes on instance runners when contributing to open source projects maintained by GitLab. The maximum of 300,000 minutes would only be possible if contributing exclusively to projects part of the GitLab product.

The total number of minutes available on instance runners is reduced by the compute minutes used by pipelines from other projects. The 300,000 minutes applies to all GitLab.com tiers.

The cost factor calculation is:

• Monthly compute quota / 300,000 job duration minutes = Cost factor

For example, with a monthly compute quota of 10,000 in the Premium tier:

• 10,000 / 300,000 = 0.03333333333 cost factor.

For this reduced cost factor:

• The merge request source project must be a fork of a GitLab-maintained project, such as gitlab-com/www-gitlab-com, or gitlab-org/gitlab.
• The merge request target project must be the fork's parent project.
• The pipeline must be a merge request, merged results, or merge train pipeline.

Reduce compute minute usage

If your project consumes too many compute minutes, try these strategies to reduce your usage:

• If you are using project mirrors, ensure that pipelines for mirror updates is disabled.
• Reduce the frequency of scheduled pipelines.
• Skip pipelines when not needed.
• Use interruptible jobs which can be auto-canceled if a new pipeline starts.
• If a job doesn't have to run in every pipeline, use rules to make it only run when it's needed.
• Use private runners for some jobs.
• If you are working from a fork and you submit a merge request to the parent project, you can ask a maintainer to run a pipeline in the parent project.

If you manage an open source project, these improvements can also reduce compute minute usage for contributor fork projects, enabling more contributions.

See the pipeline efficiency guide for more details.