GitHub Actions "The job was not acquired by Runner of type X"
The job dispatched to a runner pool that could match its labels, but no runner in that pool actually leased the job, so it sits in a held state instead of starting.
What this error means
The job stays in a non-running state and the live log shows "Waiting for a runner to pick up this job..." or "The job was not acquired by Runner of type X". No step output ever appears.
The job was not acquired by Runner of type ubuntu-latest.
Waiting for a runner to pick up this job...Common causes
No idle runner in the pool
Every runner that matches the requested labels is busy with other jobs, and the concurrency ceiling has been reached, so nothing is free to lease this one.
Transient dispatch / provisioning hiccup
On GitHub-hosted pools a backend provisioning delay can leave a job in the acquire-pending state until a runner is allocated.
How to fix it
Confirm the label resolves to a real pool
- Open the job and check the requested labels under "runs-on".
- For GitHub-hosted, confirm the label is a current image (ubuntu-latest, ubuntu-24.04).
- For self-hosted, confirm at least one online runner carries every requested label.
- Re-run the job to clear a transient acquire-pending state.
Reduce contention
If the pool is saturated, raise concurrency, split the matrix, or move to a managed runner pool with warm capacity so jobs are leased immediately instead of waiting.
How to prevent it
- Keep "runs-on" labels pinned to images and pools that actually exist.
- Track queue depth so a saturated pool is visible before it stalls jobs.
- Right-size concurrency so dispatched jobs find a free runner.