Depot Runner Not Picked Up: Job Stuck in Queued
A Depot job that never leaves "queued" almost always comes down to the runs-on label or the org connection, not a deep failure. Here are the documented causes and fixes.
Because Depot runners are a drop-in replacement adopted by changing the runs-on label, a job that stays queued usually means GitHub has nothing to schedule it onto. Depot's troubleshooting docs call this out directly for initial configuration. Below are the documented causes and fixes, attributed to depot.dev/docs/github-actions/troubleshooting.
Use a single Depot runner label, not an array
Depot's docs recommend a single runner label such as runs-on: depot-ubuntu-24.04-4 and specifically advise against arrays like [self-hosted, depot-ubuntu-24.04]. An array can prevent the runner from being allocated. Fix: set runs-on to one exact Depot label from depot.dev/docs/github-actions/runner-types.
Confirm repository access in runner groups
Per Depot's troubleshooting docs, verify the repository has access under your GitHub org settings > Actions > Runner groups > Default group. If the repo is not in a group the Depot runners can serve, the job waits. Fix: add the repository to the appropriate runner group.
Confirm the Depot GitHub App has repo permissions
Depot documents confirming that the "Depot Managed Runners" GitHub app has repository permissions in your org settings. If the app is not installed or lacks access to that repo, jobs will not be picked up. Fix: install and grant the Depot app access to the org and repository.
When the real problem is flaky failures, not setup
If your Depot jobs are picked up and fast but still fail intermittently on out-of-memory kills, disk-full errors, or registry timeouts, no runner-speed tuning removes that class of failure. Latchkey is also a drop-in managed runner reached by a runs-on label swap, but it is built around self-healing CI: it detects, diagnoses, fixes, and retries transient and mechanical failures automatically, and lists up to 58% lower per-minute cost than GitHub Actions. If troubleshooting keeps landing on flaky re-runs, it is worth piloting one workflow on Latchkey next to Depot and comparing.