BuildJet "Waiting for a runner to pick up this job" Fix
A BuildJet job that hangs on "Waiting for a runner to pick up this job" almost always means BuildJet cannot see the job: the app, permissions, the runner tag, or your concurrency limit.
When a BuildJet job sits in the waiting state and never starts, GitHub has queued it but no BuildJet runner has claimed it. According to BuildJet's troubleshooting docs there are four common causes and a reliable last-resort fix. This page walks through each. Note also that According to BuildJet's own announcement, BuildJet for GitHub Actions is winding down: new signups were halted effective February 6th, 2026, and BuildJet stops running jobs on March 31st, 2026. Dates and details can change, so verify the current status on BuildJet's site before you plan a migration.
Check the four documented causes
- The BuildJet GitHub App is not installed on the account or organization that owns the repository.
- BuildJet does not have access to this specific repository (the app is installed but the repo is not selected).
- The runner tag is wrong: a typo in the
runs-onlabel means no BuildJet runner matches. - You are requesting more vCPUs than your concurrency limit allows, so the job waits for capacity.
Verify the runs-on label
According to BuildJet's docs the label format is buildjet-<vcpu>-<os>-<version>. A single wrong character (for example ubuntu-2204 mistyped) leaves the job unmatched and waiting. Grep your workflows and compare against BuildJet's supported labels.
# confirm the exact label matches BuildJet's supported list
grep -rn "runs-on:.*buildjet" .github/workflowsThe documented last-resort fix
BuildJet's docs state: if you have checked all of the above and still see "Waiting for runner", uninstall the BuildJet GitHub Application and then reinstall it, then restart the workflow run. Reinstalling refreshes the app's permissions and repository access.
If it keeps happening
Persistent "waiting for runner" during BuildJet's wind-down may reflect capacity or service changes rather than your config. Check BuildJet's status first. Longer term, a managed runner with warm pools and self-healing (such as Latchkey) reduces queue-time and turns many transient scheduling failures into automatic retries.