GitHub Larger Runners: Autoscaling and Max Concurrency
Larger runners autoscale up to a Maximum concurrency you set. When demand exceeds that number, extra jobs queue rather than fail.
According to GitHub's docs, larger runners support autoscaling and concurrency controls, and a runner has a Maximum concurrency setting for how many jobs can run at once. If jobs are waiting, that ceiling is the usual reason. Sources: https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners and https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners.
How concurrency behaves
- Larger runners autoscale active machines up to your Maximum concurrency (per GitHub docs).
- Jobs above the limit queue until capacity frees up; they are not dropped.
- A too-low limit shows up as steady queue time during busy periods.
Adjust Maximum concurrency
Open the runner in Settings, Actions, Runners, find the Capacity section, and set Maximum concurrency to the number of concurrent jobs you want to allow. Raising it lets more machines run in parallel, which also raises potential per-minute spend. Source: https://docs.github.com/en/actions/how-tos/manage-runners/larger-runners/manage-larger-runners.
Size it against real demand
- Estimate peak parallel jobs from your busiest merge windows.
- Set Maximum concurrency at or slightly above that peak to avoid queueing.
- Remember every concurrent machine bills per minute, so balance queue time against cost.
Where managed capacity helps
If tuning a concurrency ceiling is a recurring balancing act, Latchkey managed runners draw from warm pools so heavy jobs start quickly, and self-healing keeps a transient failure from consuming a retry slot with a wasted re-run. You keep a drop-in runs-on setup.