GitHub Actions: "Waiting for a runner to pick up this job"
The job is queued and no runner has taken it yet. GitHub gives no reason on the page. These are the causes GitHub's documentation describes, from the most common: the runs-on labels, the runners themselves, the plan's concurrency limit, and runner groups. A job for a self-hosted runner is cancelled after 24 hours in the queue.
1. No runner has all the labels
For a self-hosted runner, runs-on takes a list of labels, and "jobs will be queued on runners that have all the labels that you specify" (choosing the runner for a job):
runs-on: [self-hosted, linux, x64, gpu]
- One label too many, or a typo, and no runner qualifies: the job waits until it is cancelled.
- A runner registered with
--no-default-labelshas noself-hostedlabel, and Actions Runner Controller does not support that label. - GitHub recommends unique names for your own labels: a label that matches a GitHub preset label gives no guarantee which runner takes the job (troubleshooting workflows).
2. The runners are Offline or busy
In the repository or organization: Settings > Actions > Runners lists each self-hosted runner with its labels and status (monitoring self-hosted runners):
- Idle: connected and ready.
- Active: running a job; the next job waits for it or for another runner.
- Offline: not connected to GitHub. The machine is off, the runner application is not running, or it cannot reach GitHub. Its
_diaglogs on the machine say which.
3. The plan's concurrency limit
GitHub-hosted runners run only so many jobs at once per account; the rest wait (Actions limits):
- Standard runners: 20 concurrent jobs on Free, 40 on Pro, 60 on Team, 500 on Enterprise.
- macOS: 5 at once on Free, Pro and Team (50 on Enterprise), shared with larger macOS runners.
- A big matrix or many repositories pushing at once reaches these quickly.
strategy.max-parallelorconcurrencykeeps one workflow from taking all of them. GitHub Support can raise the limits.
4. A runner group the repository cannot use
Organization runners belong to runner groups, and a group serves only the repositories it is given (Repository access: all or selected repositories). A repository the group is not given cannot use its runners. GitHub recommends self-hosted runners only for private repositories.
5. High load, and the 24-hour limit
- The start of every hour is a high-load time; scheduled workflows can be delayed then, and some queued jobs may be dropped. GitHub suggests another minute of the hour for
schedule. - A job waiting for a self-hosted runner is cancelled after 24 hours in the queue.
- For an outage, see GitHub Status.
See queued runs from IntelliJ IDEA
Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so a job still queued while the others ran shows at a glance, and your current branch's runs are in the status bar. A run that will never get a runner can be cancelled from the IDE. Reading is free; re-running, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).
GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.
More: Cancelling a run that will not stop · Re-running jobs with debug logging · Approving a deployment that is "Waiting" for review · GitHub Actions plugins for IntelliJ IDEA compared · 日本語