Skip to content
Latchkey

WarpBuild Runner Not Picked Up (Job Stuck Queued): Fix

If a WarpBuild job sits in queued and never starts, the bot is usually not installed on the repo or the runs-on label is wrong. Here is the documented fix.

A job stuck in queued is the most common first-day issue with any drop-in managed runner, and WarpBuild is no exception. Per WarpBuild's quick-start docs, two things must be in place: the WarpBuild GitHub bot installed on the repository, and a valid WarpBuild runner label in runs-on. This page walks through both. Confirm specifics in WarpBuild's docs.

Confirm the WarpBuild GitHub bot is installed

According to WarpBuild's quick-start, after signup you are redirected to install the WarpBuild GitHub bot and grant it access to your repositories. If the bot is not installed on the repo running the workflow (or its access was not granted to that repo), GitHub cannot hand the job to a WarpBuild runner and it stays queued. Fix: install or re-authorize the WarpBuild GitHub bot for the specific repository.

Confirm the runs-on label is valid

Per WarpBuild's cloud-runners docs, runner labels follow a scheme like warp-ubuntu-latest-x64-4x, warp-ubuntu-latest-arm64-8x, warp-macos-26-arm64-6x, or warp-windows-latest-x64-4x. A typo or an unsupported size means no runner matches and the job waits. Fix: copy the exact label for the type and size you want from WarpBuild's docs into your runs-on line.

Confirm scope and runner availability

Make sure the repository is under the account and organization connected to WarpBuild, and that the runner type you requested is actually offered (for example, macOS and Windows sizes differ from Linux). If a job runs in one repo but not another, the second repo is usually not covered by the bot's access. Fix: extend the bot's repository access and use a supported label.

When runners start but jobs still fail

If the fix above gets jobs running but they then fail intermittently on out-of-memory kills, disk-full errors, or registry timeouts, that is a different problem that runner setup cannot solve. Latchkey is a drop-in managed runner (also a runs-on swap) with self-healing CI that detects, diagnoses, fixes, and retries those transient failures automatically, at up to 58% lower per-minute cost than GitHub Actions. It is worth evaluating if flaky re-runs persist after setup is correct.

Frequently asked questions

Why is my WarpBuild job stuck in queued?
Per WarpBuild's docs, the WarpBuild GitHub bot is likely not installed on that repo, or the runs-on label does not match a WarpBuild runner. Fix both and retry.
What does a valid WarpBuild runner label look like?
Per WarpBuild's cloud-runners docs, labels look like warp-ubuntu-latest-x64-4x or warp-ubuntu-latest-arm64-8x. Copy the exact label for your type and size.

Related guides

See what you would save - Latchkey managed runners with self-healing. Start free →