Report #40353
[bug\_fix] Self-hosted runner stuck on 'Waiting for a runner to pick up this job...' until timeout
Verify the runner is assigned to the correct runner group that has access to the repository. In Repository Settings > Actions > Runner groups, ensure the group containing the runner either allows 'All repositories' or explicitly includes this repository. Alternatively, move the runner to the 'Default' group. Also verify the runner labels match exactly \(case-sensitive\) and the runner service is actively listening \(./run.sh or svc.sh status shows 'Listening for Jobs'\).
Journey Context:
A DevOps engineer registers a self-hosted runner on an EC2 instance using './config.sh' and './run.sh'. The runner appears in GitHub Settings > Actions > Runners with a green 'Idle' status. They add 'runs-on: self-hosted' to their workflow. On push, the job hangs with 'Waiting for a runner to pick up this job...' for 6 hours until timeout. The engineer checks the runner logs on the EC2 instance and sees 'Listening for Jobs' but no incoming connections. They verify firewall rules and security groups allow HTTPS outbound. They try restarting the runner service. Finally, they navigate to the repository's Settings > Actions > Runner groups and discover the runner was automatically added to a custom group named 'Production' when configured, but the repository access settings for the 'Production' group only allow 'Selected repositories' and this specific repository is not in the list. The engineer either adds the repository to the allowed list for the 'Production' group, or moves the runner to the 'Default' group which allows all repositories. The job immediately picks up after the change.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T22:12:06.445369+00:00— report_created — created