Beyond the News
Sign in
Web DevelopmentCloud & InfrastructureDeployment & DevOpsDeveloper Tools Active dossier

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.

Reviewed and published by Lars Jansen Updated 4 min read
Comment
First published

Key details

  1. GitHub Enterprise Cloud full enforcement begins September 25, 2026.
  2. September 9 and September 11 brownouts can block both runner registration and workflow execution.
  3. September 14, 16 and 18 are scheduled registration-and-runtime brownout days before full enforcement.
  4. v2.329.0 is the minimum for configuring or re-registering a self-hosted runner.
  5. Already-registered runners must also remain within 30 days of each new runner release to continue executing jobs.
  6. A critical security release can cause GitHub to pause job queuing until a runner is updated.
  7. GitHub Enterprise Server is not affected by this rollout.

What builders should take away

  1. Audit every self-hosted runner fleet for both the installed runner version and its update policy before the September 9 runtime brownout.
  2. Update base VM images, container images, ARC images and bootstrap scripts instead of patching only currently running hosts.
  3. 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.
  4. Test whether isolated runners can reach GitHub’s runner update service if relying on automatic updates.
  5. Add runner-version inventory and alerting so an outdated image cannot silently re-enter service after a later rebuild.

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.

What to watch next

  • 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.

Still unclear

  • 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

Direct reading behind this dossier.

2 sources
Self-hosted runners reference
GitHub Docs primary documentation

Current documentation for self-hosted runner requirements and operational model.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading
Web Development

GitHub Actions makes cache access a least-privilege workflow permission

The change turns cache poisoning from mostly a workflow-design warning into an enforceable permission boundary. Teams can let untrusted jobs restore caches without writing them, prevent reusable workflows from escalating cache access and isolate jobs that only need to publish cache entries.