GitLab · CI/CD jobs · resource groups · Checked October 28, 2026

GitLab: a job waiting for a resource

A job with resource_group runs only when the resource of its group is free. A resource group has one resource, so only one of its jobs runs at a time, across all the pipelines of the project. Until its turn, the job has the status waiting_for_resource, and its page says the following, with a View job currently using resource button when a job holds the resource (GitLab source lib/gitlab/ci/status/processable/waiting_for_resource.rb, read October 28, 2026):

This job is waiting for resource: production

When a job takes the resource and gives it back

• When the job is ready to run, it goes to waiting_for_resource instead of pending. So does a manual job once someone runs it, and a delayed job when its time comes (app/models/ci/processable.rb).
• It takes the resource when it moves on to pending, before a runner picks it up, and keeps it while it is pending and running. It gives the resource back only when it ends: success, failed, canceled or skipped. A job that holds the resource and waits for a runner keeps every other job of the group waiting too.
• A trigger job with resource_group and trigger:strategy keeps the resource until the downstream pipeline finishes.
• Before GitLab gives the resource to the next job, it takes it back from jobs that ended more than 5 minutes ago and still hold it (stale_processables in app/models/ci/resource_group.rb).

Which job goes next: the process modes

• unordered (the default): any job that is waiting for the resource.
• oldest_first: the jobs of the oldest pipeline first, counting jobs that are not ready yet (created or scheduled). A job of an older pipeline that is still created, for example behind an earlier stage that has not finished, keeps the jobs of newer pipelines waiting.
• newest_first: the same, with the newest pipeline first.
• newest_ready_first: the newest of the jobs that are waiting for the resource.

The process mode can be changed only through the API (update a resource group, process_mode). With Prevent outdated deployment jobs on, a deployment job older than the latest deployment fails when its turn comes, with "The deployment job is older than the latest deployment, and therefore failed." (app/services/ci/resource_groups/assign_resource_from_resource_group_service.rb).

How to find the job using the resource

• On the job page: View job currently using resource. Without the button, no job holds the resource.
• REST API: GET /projects/:id/resource_groups lists the groups with their process mode, current_job (GitLab 18.6 and later) gives the job using the resource, and upcoming_jobs the jobs in line. The key of the group goes URL-encoded into the path.
• GraphQL: for the waiting job, detailedStatus { action { buttonTitle path } } gives the page of the job using the resource. This also works for trigger jobs, which the pages of GitLab do not show.

curl -H "PRIVATE-TOKEN: your-token" "https://gitlab.com/api/v4/projects/group%2Fproject/resource_groups/production/current_job"
curl -H "PRIVATE-TOKEN: your-token" "https://gitlab.com/api/v4/projects/group%2Fproject/resource_groups/production/upcoming_jobs"

query {
  project(fullPath: "group/project") {
    job(id: "gid://gitlab/Ci::Build/123") { status detailedStatus { action { buttonTitle path } } }
  }
}

What to do

• The job using the resource is running or pending: it works as GitLab intends. Wait for it to end. If it stays pending, no runner picks it up: see jobs that GitLab drops as stuck.
• It is created, and the mode is oldest_first or newest_first: also as intended. Open its pipeline and look for the stage or job that holds it back.
• No job uses the resource: read upcoming_jobs. With oldest_first, if the first job is in an older pipeline that should no longer run, cancel that pipeline or the job, and repeat for the next one if needed.
• A child pipeline needs the same resource group as its parent: with oldest_first, the child waits for the deployment job of the parent, which waits for the child. Put resource_group on the trigger job in the parent instead (avoid dead locks).
• Still stuck in a busy project or with many child pipelines: GitLab names a known race condition (race conditions). Its workaround: start a new pipeline, or retry a finished job that has the same resource group.

GitLab pipelines in IntelliJ IDEA

Pipeline Inbox for GitLab CI, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of a GitLab project with their jobs by stage. It shows a job that waits for its resource as "waiting for resource", with the number of the job that uses the resource when GitLab gives one (detailedStatus.action), and keeps the pipeline refreshing until the job runs. Before version 1.0.21, it did not say which job used the resource. Viewing is free; retrying, canceling and running jobs are Pro (US$1.50 a month, with a 30-day trial).

GITLAB is a trademark of GitLab Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitLab Inc. or JetBrains.

More: GitLab job dropped as stuck or over its timeout · GitLab "You are not authorized to run this manual job" · GitLab pipeline or job refused (400, 403, 409, 429) · GitLab pipeline failed with no jobs · GitLab job log refused or empty · GitLab pipeline plugins for IntelliJ IDEA, compared · 日本語