GitHub Actions Self-Hosted Runner Failed to Register on August 24 — Version Brownout Fix

If a GitHub Actions self-hosted runner stopped registering or re-registering on August 24, 2026, first check its version. GitHub has started scheduled brownouts for its new minimum-version policy on GitHub Enterprise Cloud.

The first brownout targets runner configuration. During that window, self-hosted runners older than version 2.329.0 cannot be registered or re-registered. This is separate from the rolling execution policy: runners must also remain within 30 days of a new runner release to continue receiving jobs once enforcement applies.

Confirm the Installed Version

From the runner installation directory, check the diagnostic logs or start the runner and inspect its startup output. In a container or Kubernetes deployment, inspect the image tag used by the runner pod.

Do not solve this by repeatedly generating new registration tokens. A fresh token will not make an unsupported runner binary eligible to register.

The Safe Fix

1. Confirm the runner is not actively executing a job.
2. Back up only the configuration information your recovery procedure requires; do not copy credentials into an image.
3. Download a current runner release from GitHub's official Actions runner repository.
4. Verify the package using the checksum published for that release.
5. Replace the old binary or update the container image.
6. Reconfigure the runner with a new short-lived registration token if required.
7. Run a small workflow that targets the runner's labels.

Use a current release rather than upgrading only to 2.329.0. That version is the configuration floor announced for this enforcement event, but GitHub's execution requirement moves with new releases.

If the runner is still disconnected after upgrading, follow our self-hosted runner offline troubleshooting guide.

Kubernetes and Autoscaling Runners

For Actions Runner Controller or an internal autoscaler, rebuilding one machine is not enough. Update the runner image reference in the deployment source, roll out the controller-supported version, and verify newly created pods report a current runner release.

Avoid mutable image tags when you need predictable rollouts. Pin a reviewed image version, automate a scheduled update pull request, and alert when the deployed runner age approaches the 30-day limit. Our Kubernetes self-hosted runner guide covers the underlying deployment pattern.

Important 2026 Dates

GitHub announced Enterprise Cloud brownouts beginning August 24, followed by additional windows from August 31 through September 18. Full enforcement is scheduled for September 25, 2026. GitHub Enterprise Server is not included in this particular enforcement announcement.

Check the official changelog before relying on these dates because platform schedules can change.

Prevent the Next Outage

• Track the installed version in inventory.
• Subscribe to official runner releases.
• Test updates in a non-production runner group.
• Automate image rebuilds and staged rollout.
• Alert on runners that have not been updated recently.
• Keep a GitHub-hosted fallback where workload and security policy allow it.

The key distinction is that August 24 begins a configuration brownout, not a universal claim that every old runner immediately stops every job. Upgrade now anyway: registration enforcement and the rolling 30-day execution requirement make permanently pinned runner binaries an operational risk.

Sources

• GitHub Changelog: minimum-version enforcement timeline
• GitHub Actions runner releases