GitHub Actions Self-Hosted Runner Enforcement Hits September 25: Check Your Version Now

GitHub Actions self-hosted runner minimum version enforcement reaches full effect on September 25, 2026 for GitHub Enterprise Cloud, one day from this writing. Runners below v2.329.0 will stop registering entirely, and runners already registered below the minimum version will stop picking up workflow jobs, even if they were working fine yesterday. If your CI/CD pipeline relies on self-hosted runners and nobody has checked their versions recently, this is worth verifying today, not after a pipeline silently starts failing.

What’s actually changing

GitHub has been building toward this enforcement in stages: brownouts (temporary, intermittent enforcement windows meant to surface the problem before it becomes permanent) began August 24, 2026 and ramped up through mid-September. Full, permanent enforcement lands September 25, 2026 for GitHub Enterprise Cloud specifically. After that date:

• Self-hosted runners running a version below the minimum required cannot register or re-register with GitHub at all.
• Runners that were already registered but are below the minimum version required to execute jobs will simply stop running workflow jobs, they don’t get an obvious error that points directly at the version mismatch, jobs just start queuing or failing.
• Going forward, runners need to stay within 30 days of a new runner release to keep receiving jobs once enforcement is active, this isn’t a one-time update-and-forget fix, it establishes an ongoing update cadence requirement.

The minimum version for registration is v2.329.0 or later. GitHub Enterprise Server is not impacted by this specific timeline. Organizations using GitHub Enterprise Cloud with Data Residency were actually on an earlier enforcement date, July 31, 2026, so those environments should already be compliant or already broken, worth double-checking either way.

How to check your runners right now

# On each self-hosted runner host, check the installed version
cat /path/to/actions-runner/.runner
# or, if the runner service is active:
./run.sh --version

# From the GitHub organization/repository settings UI:
# Settings > Actions > Runners, each runner's listed version
# is visible directly without needing host access to every machine

For any runner below v2.329.0, update it now rather than waiting for enforcement to actually break a pipeline. The runner software update process is a straightforward download-and-replace of the runner package followed by a service restart, but if you manage many self-hosted runners across multiple hosts, script this as a fleet-wide check rather than verifying host by host, the point of this deadline is exactly that manual per-host checking doesn’t scale and staying current needs to become routine.

Why this deadline exists, not just what it requires

Minimum version enforcement for CI/CD runners is a security measure as much as a compatibility one. Older runner versions can carry known vulnerabilities in how they handle job execution, secrets, and communication with GitHub’s coordination service, and CI/CD infrastructure specifically has become an increasingly common target precisely because a compromised runner sits in a trusted position with access to secrets, source code, and often deployment credentials. Forcing runners to stay within a recent version window is GitHub reducing the population of outdated, potentially vulnerable runner software across its ecosystem, not an arbitrary bureaucratic requirement.

This connects to a broader pattern worth taking seriously regardless of this specific deadline: CI/CD pipelines have become a real, actively targeted attack surface. Pin third-party GitHub Actions to a specific commit SHA rather than a mutable version tag (a compromised or re-tagged action version is a supply chain risk that SHA-pinning specifically defeats), audit workflows for dangerous trigger patterns like pull_request_target combined with checkout of untrusted PR code, and treat runner and action currency as an ongoing operational responsibility, not a one-time setup task.

Frequently asked questions

My self-hosted runner already stopped picking up jobs before September 25. Why?
The brownout period (temporary enforcement windows) began August 24 and ramped up through mid-September specifically to surface exactly this kind of problem before the deadline became permanent. If you saw intermittent job failures or queuing during that window, that’s very likely this issue, and it’s worth confirming your runner version now rather than waiting for the September 25 full enforcement to make the problem permanent.

Does this affect GitHub-hosted runners (the ones GitHub manages, not self-hosted)?
No, this enforcement is specifically about self-hosted runners, ones your organization operates on its own infrastructure. GitHub-hosted runners are managed and kept current by GitHub directly and aren’t subject to this particular deadline.

We’re on GitHub Enterprise Server, not Enterprise Cloud. Does this deadline apply to us?
Based on GitHub’s own stated timeline, GitHub Enterprise Server is not impacted by this specific enforcement date. Confirm against GitHub’s current changelog for your specific product tier though, since enforcement timelines for different GitHub products have been staged separately and are worth checking directly rather than assuming based on another tier’s schedule.