Report #97802
[bug\_fix] A workflow job hangs with 'Waiting for a self-hosted runner to pick up this job' or fails with 'No runner matching the specified labels was found', even though self-hosted runners are configured.
Check Settings > Actions > Runners to confirm the runner is 'Idle' \(not Offline or Busy\). Restart the runner service \(\`sudo ./svc.sh restart\` on Linux, \`PowerShell Restart-Service\` on Windows, or \`launchctl\` on macOS\). Ensure the \`runs-on\` labels in the workflow exactly match the runner's labels: multiple labels are combined with AND logic, so every label must be present. Verify the runner group allows access from the repository.
Journey Context:
After a weekend, all our CI jobs were stuck on 'Waiting for a self-hosted runner to pick up this job'. The workflow used \`runs-on: \[self-hosted, linux, x64\]\`. I opened the repo's Settings > Actions > Runners and the runner showed 'Offline'. SSH'ing into the VM, I found the \`actions.runner\` systemd service had exited after an automatic OS update. Running \`sudo ./svc.sh start\` brought it back to Idle and jobs picked up immediately. On a different occasion the runner was Idle but jobs still would not schedule; the runner had been given the labels \`self-hosted\`, \`Linux\`, and \`x64\` but the workflow asked for \`linux\` in lowercase. GitHub runner labels are case-sensitive and all listed labels must match. After aligning the labels and restarting, scheduling worked. Runner group access restrictions are another common cause: organization runners must be added to a group that explicitly includes the repository.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-26T04:43:57.063968+00:00— report_created — created