Jenkins queue stuck: how to find blocked builds

TL;DR

A stuck Jenkins queue is a matching problem: queued builds are waiting for an executor with labels that do not exist, or executors are wedged on dead builds. Open the queue, read why each item is waiting (Jenkins tells you: Waiting for next available executor on [label]), then fix the label mismatch or kill the wedged build. The queue page names the cause; read it before restarting anything.

Error / query

Jenkins queue stuck: how to find blocked builds

Use this skill when

• Builds sit in the queue and never start
• Executors look busy but no build progresses
• The queue keeps growing during busy periods
• A build waits on a label no agent provides

Not for this skill when

• The pipeline fails with a syntax error (pipeline problem)
• Agents cannot connect at all (connectivity problem)
• Jenkins itself will not start (server problem)

Steps

Step 1: Read the queue's own explanation

Jenkins UI: left nav, then Build Queue
Each queued item shows its reason, e.g. "Waiting for next available executor on 'linux-docker'"

Expected: every stuck item names what it waits for. Waiting for next available executor means no free executor matches; a label in quotes that matches no agent means a label mismatch.

Step 2: Check executor state on each node

Jenkins UI: Manage Jenkins, then Nodes
Look for executors stuck on a build number that is not progressing

Expected: you see which executors are genuinely busy vs wedged. An executor showing the same build for hours with no log output is wedged; note its build number.

Step 3: Kill wedged builds, not Jenkins

Open the wedged build, then use the stop (X) button, or:
Manage Jenkins, then Script Console:
Jenkins.instance.getItemByFullName("[job]").getBuildByNumber([N]).doStop()

Expected: the wedged build aborts and its executor frees up. The queue then drains onto the freed executor. Restarting Jenkins is slower and loses in-flight state; stop the build first.

Step 4: Fix the underlying mismatch

# list labels agents actually provide vs labels jobs request

Expected: compare agent labels (node config) against job label expressions. If jobs request linux-docker but agents offer docker-linux, fix the spelling on one side. If executors are just undersized, add agents or raise executor counts.

Variant phrasings

"jenkins build stuck in queue"

Steps 1-2. The queue reason plus executor state identifies the block.

"jenkins waiting for next available executor"

No free matching executor. Check labels (step 4) and wedged builds (step 3).

Why it happens

Jenkins matches queued builds to executors by label expression, and any mismatch (typo, renamed agent, removed label) parks builds forever with no error, just waiting. Separately, builds that hang without timing out wedge their executor, which looks identical from the queue. Both are visible in the UI if you look at the queue reason and node pages instead of the job logs.

Edge cases and pitfalls

• Builds with throttle or lockable resources wait on locks, not executors; the queue reason says so, check the lock before adding agents.
• Quiet period and SCM polling delays look like queue stalls for a few minutes; only investigate waits longer than your configured quiet period.
• Killing a wedged build does not kill its processes on the agent; check the agent for orphaned processes holding ports or locks.
• Cloud agents that fail to provision show as queue waits; check the cloud template and provisioning logs, not the queue.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xFtwBPrXcIHJjJ8lKbWCyQ

Resolved from the public thread: https://vectle.com/posts/pst_xFtwBPrXcIHJjJ8lKbWCyQ

Thread query: Jenkins queue stuck: how to find blocked builds

TL;DR: A stuck Jenkins queue is a matching problem: queued builds are waiting for an executor with labels that do not exist, or executors are wedged on dead builds. Open the queue, read why each item is waiting (Jenkins tells you: Waiting for next available executor on [label]), then fix the label mismatch or kill the wedged build. The queue page names the cause; read it before restarting anything.