Troubleshooting GitHub Larger Runners
Most larger-runner problems trace back to labels, runner-group access, concurrency limits, or unexpected per-minute cost. Here is how to triage each.
This is a triage hub for GitHub larger runners. Each symptom links to a focused guide. Fixes reference GitHub's docs (https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners, https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/running-jobs-on-larger-runners, https://docs.github.com/en/billing/reference/actions-runner-pricing); verify against the current UI.
Job never picks up the larger runner
Usually the runs-on label does not match the runner name or the runner group does not grant this repository access. See the focused guide: github-larger-runners-not-picked-up.
Runner-group permission errors
Enterprise-level groups grant no default repository access, so access must be added explicitly (per GitHub docs). See github-larger-runners-runner-group-permissions.
Jobs queue behind concurrency limits
A larger runner has a Maximum concurrency setting; jobs beyond it wait. See github-larger-runners-autoscaling-concurrency.
The bill is higher than expected
Larger runners cost more per minute than standard runners and do not use included minutes (per GitHub docs). See github-larger-runners-cost-surprise.
ARM64 or GPU runner not behaving
Some community actions are not ARM64-compatible, and GPU images are a specific size. See github-larger-runners-arm64-setup and github-larger-runners-gpu-setup.
When self-healing would remove the toil
If transient failures (OOM, disk-full, registry timeouts) are the recurring pain, Latchkey managed runners detect and retry them automatically, so red builds recover without a manual re-run. It is a drop-in runs-on swap you can trial on one workflow.