GitLab job stuck in pending? Why it happens and how to fix it

A job sits at Pending, the pipeline doesn’t move, and the job page says “This job is stuck”. Your script is fine: GitLab hasn’t found a runner that may run the job. Here is what each version of the message means in GitLab 19.5, how to fix the usual causes, and when GitLab gives up on the job.

Pending, stuck or waiting

• Pending: the job is ready and waits for a runner to pick it up. If the runners are only busy, it starts when a free runner that matches reaches it in the queue.
• Stuck: no online runner can run it at all. The job page shows a warning, and the pipeline list marks the pipeline stuck.
• Waiting for resource: the job uses a resource_group, and another job holds that resource. See below.

What the warning says

The job page says	What it means
This job is stuck because you don’t have any active runners that can run this job.	The job has no tags, and no runner that isn’t paused is available to the project: none is assigned, group and instance runners are off, or all are paused.
This job is stuck because the project doesn’t have any runners online assigned to it.	The job has no tags. The project has runners that aren’t paused, but none that is online can take it: they’re offline, run only tagged jobs, or are protected and the branch isn’t.
This job is stuck because of one of the following problems. There are no active runners online, no runners for the protected branch, or no runners that match all of the job’s tags:	The job has tags, listed under the message. Either no runner is online, no online runner has all of them, or the ones that do are protected and the branch isn’t.

Fix it

Check the tags

A runner takes a job only if it has every tag the job lists, and a runner with Run untagged jobs turned off never takes a job without tags.

build:
  tags:
    - docker # waits for an online runner tagged docker
  script: make

Compare the job’s tags: with the runners’ tags in Settings › CI/CD › Runners. Fix the runner’s tags and the waiting job starts on its own. Fix the job’s tags instead and you need a new pipeline: a job keeps the tags it was created with, and so does a retry of it.

On GitLab.com, untagged jobs run on GitLab’s hosted runners, saas-linux-small-amd64 by default, and a tag such as saas-linux-medium-amd64 picks a bigger machine (the largest sizes are for Premium and Ultimate). A tag that only a runner of your own has waits for that runner.

Check that a runner is online

• Settings › CI/CD › Runners lists the runners the project can use, with their status. A runner counts as online if it contacted GitLab in the last two hours.
• A paused runner takes no new jobs. Resume a project runner from that list; a group Owner resumes a group runner from the group’s Build › Runners, and an administrator resumes instance runners.
• On the runner’s machine, gitlab-runner status shows whether the service is running, and gitlab-runner verify checks that its registered runners can still connect to GitLab. gitlab-runner restart restarts it.

Check protected runners

A runner marked Protected runs jobs only on protected branches and protected tags, and in merge request pipelines if the project allows it. A pipeline for a feature branch waits for it in vain: unprotect the runner, add one that isn’t protected, or run the job on a protected branch. (If you can’t push there, see why GitLab says you’re not allowed to push to a protected branch.)

Check that the project may use the runner

• Instance runners are on by default for GitLab.com projects, but a project or its group can turn them off; on GitLab Self-Managed, an administrator sets the default for new projects. Turn them on with Turn on instance runners for this project under Settings › CI/CD › Runners, if the group allows it.
• Project runners run jobs only for the projects they’re assigned to. Group runners run them for the projects in their group and its subgroups, as long as Turn on group runners for this project is on.

Waiting for resource

A job with resource_group runs only when no other job holds the same resource, so two deploys to production never overlap. Its page says “This job is waiting for resource:” and the resource’s name.

• Select View job currently using resource to see which job holds it. If that job is running or pending, wait for it to finish.
• If nothing holds the resource and the job still waits, list the resource group’s upcoming jobs with the API. With the Oldest first process mode, a job from an older pipeline that should no longer run can be first in line: try cancelling that pipeline or job (how to cancel a GitLab pipeline).
• GitLab’s docs also describe a race in busy pipelines. As a temporary workaround, start a new pipeline, or rerun a finished job that uses the same resource group.

A pipeline that waits on blocked is a different case: a manual job is waiting for someone to run it. See how to run a manual job.

When GitLab gives up

GitLab checks pending jobs once an hour and fails the ones that have waited too long:

• Stuck for about an hour, with no matching runner online: “The job was stuck in pending state with no matching runners available. Check your runner tags or configuration”. Because of the hourly check, it can take up to two hours.
• Pending for a day, even with matching runners: “The job was stuck in pending state with matching runners available. Check your job configuration or try again”.

Fix the cause first, then retry the job, or run a new pipeline if you changed its tags. Retrying while no runner fits only queues it again.

On your phone

In MergeBell, a job that hasn’t started shows as Pending in its pipeline, or Waiting when it’s queued for a resource group, and you can cancel it from the phone on the free tier. The fix lives in your runner settings, so that part needs GitLab in a browser. When GitLab gives up and your merge request’s pipeline fails, the “Pipeline failed” To-Do arrives as a push, free and checked every five minutes; with Pro, a pipeline watch sends one when a branch’s pipeline fails.