GitHub will stop queuing jobs to outdated self-hosted runners on Sep 25, 2026

Self-hosted GitHub Actions runners on outdated versions will stop receiving jobs permanently on September 25, 2026, according to a post on dev.to. Before that cutoff, GitHub is running brownouts on September 7, 9, 11, 14, 16 and 18, during which outdated runners neither register nor execute jobs.

The failure is quiet

The post's central warning is that the breakage is easy to miss. Workflows do not fail with a visible error; every job targeting an outdated runner simply sits in the "Queued" state, and the clearest signal is a runner log line stating that the runner version is deprecated and cannot receive messages.

Teams running Actions Runner Controller (ARC) are particularly exposed, the author notes, because ARC disables auto-update by design. A pinned image tag in Helm values is, in effect, an outage scheduled for a date nobody has looked up.

GitHub shipped a deprecation API

On September 3, 2026, GitHub added an endpoint that returns end-of-life dates for any runner version. Called with a version such as 2.334.0, it returns that version along with the date runtime support ends and the date registration ends.

The author reports two findings from running it against real versions. First, although the documented rule is that support ends 30 days after release, the API currently returns roughly 63 to 71 days for recent versions, so expiry dates computed from release dates are wrong in both directions. Second, the runner list endpoint now includes each runner's version, so an audit no longer needs an agent installed on the machines.

Auditing live runners and pinned versions

To make the endpoints practical, the author published an open-source gh extension, gh-runner-eol, under the MIT licence. An organisation-wide audit groups live runners by version and flags each group as overdue, warning or OK. In the author's example output, 43 runners ran three versions: 18 on v2.334.0, whose runtime support ended on August 10, 2026; 12 on v2.336.0, with support ending September 15, 2026; and 13 on v2.337.0, with no end-of-life date scheduled.

The extension's scan mode also greps Dockerfiles, ARC Helm values, RUNNER_VERSION variables and download URLs for pinned versions, resolving each against the API. That covers runners that exist only as configuration — images not yet scaled up, which a dashboard of live runners cannot see.

It can additionally run as a GitHub Action with SARIF output, so a pinned version shows up as a Code Scanning annotation on the pull request that introduces it, and it exits non-zero on overdue results so a weekly schedule can raise an alert.

Token and scope caveats

The default workflow GITHUB_TOKEN cannot read self-hosted runners and returns a 403, so the extension needs a fine-grained PAT or GitHub App token with self-hosted runner read permission at organisation level, or administration read at repository level. A scan-only mode works without any of that. The tool is also deliberately read-only: it answers what breaks and when, while ARC, GARM and similar tools handle the actual upgrading.

Why it matters

September 25 turns a slow housekeeping chore into a hard deadline. After that date, workflows targeting an outdated self-hosted runner will queue indefinitely instead of failing loudly — the kind of outage teams discover late. The brownouts from September 7 offer a preview, but only on six days.

The remediation itself is simple: update runners and stop pinning stale ARC image tags. The real work is finding every affected runner and every pinned version across an organisation, and the new deprecation API plus audit tooling closes that gap. The mismatch between the documented 30-day window and the 63 to 71 days the API actually returns is one more reason to stop hand-computing expiry dates from release schedules.