# GitHub Actions is starting runtime brownouts for outdated self-hosted runners GitHub’s delayed self-hosted runner enforcement is now in its operational phase: Enterprise Cloud brownouts began September 7, runtime blocking starts September 9, and full enforcement begins September 25 for runners that fall outside GitHub’s supported version window. Teams with pinned, custom-image or auto-update-disabled GitHub Actions runners can now see registration or job execution fail before the September 25 cutoff. The migration is not just a one-time jump to v2.329.0: already-registered runners must also stay within 30 days of the latest runner release. - Status: Active - Published: 2026-09-08T22:44:34+12:00 - Updated: 2026-09-08T22:44:34+12:00 - Categories: Web Development, Cloud & Infrastructure, Deployment & DevOps, Developer Tools - Tags: CI/CD, GitHub, GitHub Actions, migration, self-hosted runners - Canonical HTML: https://beyondthe.news/dossiers/github-actions-self-hosted-runner-version-enforcement-september-2026 ## What changed GitHub has resumed the self-hosted runner version enforcement it paused earlier in 2026 and has moved GitHub Enterprise Cloud into a staged brownout period. Registration-only brownouts ran on August 24, August 31, September 2 and September 7. On September 9 and September 11, brownouts expand so unsupported runners can also be prevented from executing workflow jobs. September 14, 16 and 18 are scheduled as registration-and-runtime brownout days, with full enforcement beginning September 25. New or re-registered runners must be on v2.329.0 or later, while already-registered runners must remain within GitHub’s normal 30-day update window after each runner release. ## Why it matters A self-hosted runner can appear healthy until GitHub stops accepting its registration or stops queuing jobs to it. That creates a specific failure mode for enterprises using immutable runner images, Actions Runner Controller images, air-gapped update processes or `disableUpdate=true`: pinning a runner to the documented registration floor is not enough for continuing job execution. Teams need an ongoing runner-update process, not merely a one-off September upgrade. ## The brownouts have moved from warnings into runtime failures GitHub’s September schedule starts with registration-only interruptions and then adds runtime blocking. September 9 is the first scheduled Enterprise Cloud brownout where outdated self-hosted runners can both fail configuration and stop receiving workflow jobs. ## There are two different version boundaries The v2.329.0 floor applies when configuring or re-registering a runner. Separately, GitHub requires already-registered runners to install each new runner release within 30 days. A runner can therefore satisfy the registration minimum and still later become too old to execute jobs. ## Custom and pinned runner images need continuous maintenance Runners with automatic updates enabled should normally track the execution requirement if they can reach the update service. Runners with auto-update disabled, custom ARC images, cached VM templates or long-lived golden images need an explicit process to rebuild and redeploy when new runner versions ship. ## GitHub Enterprise Server is outside this September rollout The September 25 enforcement described by GitHub applies to github.com / GitHub Enterprise Cloud. GitHub Enterprise Server customers are not included in this rollout. ## Key details - GitHub Enterprise Cloud full enforcement begins September 25, 2026. - September 9 and September 11 brownouts can block both runner registration and workflow execution. - September 14, 16 and 18 are scheduled registration-and-runtime brownout days before full enforcement. - v2.329.0 is the minimum for configuring or re-registering a self-hosted runner. - Already-registered runners must also remain within 30 days of each new runner release to continue executing jobs. - A critical security release can cause GitHub to pause job queuing until a runner is updated. - GitHub Enterprise Server is not affected by this rollout. ## Builder takeaways - Audit every self-hosted runner fleet for both the installed runner version and its update policy before the September 9 runtime brownout. - Update base VM images, container images, ARC images and bootstrap scripts instead of patching only currently running hosts. - Do not pin permanently to v2.329.0. Treat runner updates as a continuing maintenance requirement because the effective execution minimum advances as new releases ship. - Test whether isolated runners can reach GitHub’s runner update service if relying on automatic updates. - Add runner-version inventory and alerting so an outdated image cannot silently re-enter service after a later rebuild. ## What to watch - Whether September brownouts reveal widespread failures in fleets using pinned or custom runner images. - Any further changes to the September 25 enforcement date or minimum registration version. - How GitHub communicates future runner releases that advance the effective 30-day execution floor. - Whether enterprise runner-management tooling exposes stronger fleet-wide version compliance reporting. ## Uncertainties - The minimum version required for continued job execution is not a fixed number; it advances with later runner releases under the 30-day policy. - GitHub may still adjust the staged rollout if brownouts expose severe ecosystem disruption. - A runner’s exact failure behavior depends on whether the issue is registration-time version enforcement, ordinary runtime deprecation or a critical-security update. ## Sources - [GitHub Actions: Minimum version enforcement timeline for self-hosted runners](https://github.blog/changelog/2026-06-12-github-actions-minimum-version-enforcement-timeline-for-self-hosted-runners/) — GitHub Changelog · primary · 2026-06-12T00:00:00+12:00. Primary source for the September brownout schedule, September 25 Enterprise Cloud enforcement date, v2.329.0 registration floor and 30-day runtime update rule. - [Self-hosted runners reference](https://docs.github.com/en/actions/reference/runners/self-hosted-runners) — GitHub Docs · primary documentation. Current documentation for self-hosted runner requirements and operational model.