LEARN. PRACTICE. GROW.Concept and mechanism
An available runner is not necessarily eligible. Selection considers labels and authorized groups; all relevant conditions must match. Start diagnosing queued state from the effective request, repository access, runner state, and eligible-set capacity. Avoid removing restrictions merely to make a job proceed. Those restrictions can separate production networks, identities, and data. On a persistent runner, state left by one job can affect the next. Running external code in that environment requires assessing what it can read, change, and leave for future executions, including tools, working directories, and network access. Total enterprise capacity alone is therefore a misleading operational indicator.
Guided application
In a fictional payments deployment, ten free runners outside the authorized group do not resolve missing capacity inside the approved boundary. L3 should identify selection mistakes versus actual unavailability, while the manager evaluates the release-window deadline. Ephemeral runners receive one job before deregistration; the team remains responsible for destruction and external log preservation. For GitHub-hosted images, declare required tool versions and record the observed environment: an OS label does not freeze the entire image. When consuming private workflows, also confirm caller policies and called-repository sharing before attributing failure to infrastructure.
Correct group, missing payments label: queued can be an eligibility problem rather than global saturation.
Common pitfalls
Online as eligible; label as isolation; deregistration as disk erasure; hosted image as frozen toolchain.
Related topics: Events, filters, and dependencies · Data, outputs, and service networking · Reuse, artifacts, and troubleshooting
Measure capacity within the authorized boundary and preserve evidence outside disposable runners.
Reference: Self-hosted and ephemeral runners · GH-200 skills measured January2026;study guide updated2026-02-05