Jenkins Builds Stuck 'Waiting for Next Available Executor' While Agents Look Connected

A pipeline sits in the build queue showing Waiting for next available executor or Still waiting to schedule task, yet Manage Jenkins → Nodes shows your agents as connected. This is almost always a scheduling mismatch, not a connectivity failure: the controller can see the agent, but no online agent is eligible to run the job. The fix is usually a label string, a node usage setting, or a cloud provisioning cap — and you can identify which one in a few minutes by reading the queue item's own hover text.

What the condition looks like

The build never leaves the queue. Hovering over the queued item shows a message like Waiting for next available executor on <label> or There are no nodes with the label '<label>'. Meanwhile the agent list shows green (connected) nodes. The key insight: connected and eligible are different things. A node can be online and still refuse the job because of its label configuration, usage mode, executor availability, or offline flag.

Cause and diagnostic table

Ordered checks

1. Read the queue hover text. On the controller UI, hover over the queued build. Jenkins tells you the exact blocking reason — an unmatched label, all executors busy, or a specific node it is waiting for. This single step resolves most guesswork.
2. Compare label strings. Open the pipeline's agent { label '...' } and the node configuration page side by side. Check spelling, case, and extra spaces. Remember that a node set to "Only build jobs with label expressions matching this node" will ignore jobs whose labels do not match, even if it is idle.
3. Check node state. On the node page, confirm it is not marked temporarily offline (the offline reason is shown and often explains everything, e.g. a disk-space monitor tripped it), and that it has free executors.
4. Review the logs. In Manage Jenkins → System Log, look for provisioning or remoting errors. For cloud agents, each cloud has its own provisioning/activity log showing why an agent failed to launch — expired credentials, a missing AMI, a subnet with no free IPs, or a provider-side quota.
5. Isolate with a trivial job. Create a freestyle job, set "Restrict where this project can be run" to the same label, and give it a single step like echo ok. If the trivial job also queues, the problem is node/label configuration, not your pipeline. If it runs, the problem is inside the pipeline definition (for example, a different label in a later stage).

Fixes tied to findings

Label mismatch: make the strings identical. A minimal reproduction you can use to confirm the diagnosis is a pipeline with a deliberately wrong label:

pipeline {
  agent { label 'linux-agnet' }  // deliberate typo
  stages {
    stage('test') { steps { echo 'never runs' } }
  }
}

Queue it and confirm the hover message names the unmatched label. Then fix the typo and confirm the build schedules. This takes two minutes and proves the scheduling path works.

Usage mode: switching a node from "Only build jobs with label expressions matching this node" to "Use this node as much as possible" widens what the agent accepts. Do this deliberately: on sensitive agents (deployment credentials, production network access), the looser setting can route untrusted jobs there. Prefer fixing the label expression instead.

Busy executors: raising the executor count on a node helps only if the host has CPU and memory headroom; otherwise you trade queueing for slow builds. Splitting the workload across more agents is usually the better fix.

Cloud agents never launch: check the provider console before changing Jenkins. Expired IAM credentials, an account-level vCPU quota, or a deleted AMI will produce provisioning exceptions in the cloud plugin's log that no Jenkins-side change will fix. If the cloud's instance cap is reached, either raise the cap in the cloud configuration or reduce demand.

Verifying the fix

After each change, rerun the trivial pinned freestyle job and confirm it leaves the queue and starts on the expected agent. Then re-run the real pipeline. For cloud agents, watch the cloud's activity page during the run to confirm the agent launches without exceptions. If the queue hover text changed from "no nodes with the label" to an actual executor assignment, scheduling is healthy.

When to escalate

Escalate to your Jenkins administrators or the relevant plugin maintainers when: the controller log shows repeated provisioning exceptions after you have fixed credentials and quotas; remoting channel errors persist across agent restarts; or the blockage started immediately after a controller or plugin upgrade (in which case capture the queue hover text, the system log excerpt, and the plugin versions before rolling anything back). Exact log locations and UI labels vary between Jenkins LTS lines, so verify paths against your installed version before reporting.