Quick answer: If your GitHub Actions workflows use self-hosted runners on github.com, update them now. GitHub’s final week of configuration-and-runtime brownouts is September 14, 16 and 18, 2026, from 11:00 a.m. to 3:00 p.m. ET (15:00–19:00 UTC). Full GitHub Enterprise Cloud enforcement begins September 25. During a brownout, an unsupported runner can fail to register and can stop receiving or executing jobs. [1]
Minimum is not the same as current: version 2.329.0 is the minimum for configuration or re-registration, but job execution also requires installing every new runner release within 30 days. GitHub says a runner pinned forever to 2.329.0 will eventually stop receiving jobs. Use the version offered in your repository or organization’s runner download instructions rather than treating 2.329.0 as a permanent target. [1][3]
September 2026 brownout and enforcement dates
| Date | Window | Expected impact on unsupported runners |
|---|---|---|
| September 14 | 11 a.m.–3 p.m. ET / 15:00–19:00 UTC | Configuration and runtime blocking |
| September 16 | 11 a.m.–3 p.m. ET / 15:00–19:00 UTC | Configuration and runtime blocking |
| September 18 | 11 a.m.–3 p.m. ET / 15:00–19:00 UTC | Configuration and runtime blocking |
| September 25 | Full enforcement begins | Unsupported registrations are blocked; outdated connected runners can stop executing jobs |
These dates apply to GitHub Enterprise Cloud on github.com. GitHub Enterprise Cloud with Data Residency reached full enforcement on July 31, while GitHub Enterprise Server is not affected by this specific cloud rollout. [1]
Five-minute runner audit
- Confirm scope: search workflow files for
runs-on: self-hosted, custom runner labels or runner groups. - Open the inventory: in the relevant repository or organization, go to Settings → Actions → Runners. GitHub shows each registered runner’s name, labels and status there. [2]
- Record the actual version: query the REST inventory below. The current API response includes a
versionfield for each runner. [4] - Check the deployment source: inspect VM templates, container images, startup scripts, ARC scale sets and disaster-recovery images. Updating one currently running host does not repair a stale image that will recreate the old version.
- Test spare capacity: upgrade a canary runner, run a representative workflow, then roll through the fleet while enough known-good capacity remains online.
List organization runners and versions with the GitHub CLI
ORG="your-organization"
gh api -H "X-GitHub-Api-Version: 2026-03-10" --paginate "/orgs/$ORG/actions/runners?per_page=100" --jq '.runners[] | [.name, .os, .status, .busy, .version] | @tsv'The organization endpoint requires suitable organization administration permission. Repository- and enterprise-level endpoints are also documented; use the scope that owns your runners. Do not paste access tokens into scripts, tickets or command output. [4]
Check a runner version’s end-of-life schedule
ORG="your-organization"
VERSION="2.329.0" # replace with the version found in your inventory
gh api -H "X-GitHub-Api-Version: 2026-03-10" "/orgs/$ORG/actions/runners/deprecations/$VERSION"GitHub documents a dedicated organization endpoint that returns a runner version and the dates when its registration or runtime support ends. This is safer than assuming that “2.329.0 or later” alone guarantees runtime eligibility. [4]
How to update without breaking CI
- Use GitHub’s generated download instructions. Open Settings → Actions → Runners → New self-hosted runner for the correct OS and architecture. GitHub notes that runner releases are progressive, so the globally latest tag may not yet be the version offered to every enterprise or organization. [3]
- Back up configuration, not job workspaces. Preserve your service identity, labels, runner group, network policy and deployment automation. Treat job work directories as disposable.
- Drain or isolate one runner. Prevent new jobs from landing on the canary, allow its current job to finish, then stop its service.
- Replace the runner binary or image. For ephemeral/container fleets, rebuild and redeploy the source image instead of patching only live containers.
- Start and inspect the service. On Linux,
./svc.sh statuschecks the installed service. Runner and update logs are stored under_diag; systemd installations can also be inspected withjournalctl. [2] - Run a real validation workflow. Exercise checkout, caches, artifacts, containers and any custom labels used by production jobs.
- Roll forward gradually. Keep enough healthy runners available for critical queues and monitor for GitHub’s outdated-runner annotations.
Auto-update enabled vs disabled
| Runner model | What to verify |
|---|---|
| Persistent runner, auto-update enabled | Confirm it can reach GitHub’s update services and that SelfUpdate logs show successful updates. |
| Persistent runner, auto-update disabled | Build a recurring release-monitoring and upgrade process; every major, minor and patch release counts. |
| Ephemeral VM or container runner | Update the golden image and provisioning pipeline. Recreate runners from the new image. |
| Actions Runner Controller | Review the runner image/tag used by the scale set and perform a controlled rollout with spare capacity. |
GitHub says self-hosted runners update automatically by default. When updates are disabled with --disableupdate, each release must be installed within 30 days; critical security releases can stop job queuing sooner. Update connectivity requires access to GitHub release and object-storage domains listed in the runner reference. [5]
Why a runner may still fail after an update
- The old image returned: autoscaling or recovery automation recreated a runner from a cached template.
- Update traffic is blocked: a proxy, firewall or TLS interception policy prevents access to GitHub’s update services.
- The service never restarted: the files changed, but the active service still uses the old installation or failed to start.
- Labels no longer match: the replacement runner registered without a label required by
runs-on. - No matching capacity is online: GitHub notes that a job can remain queued until its 24-hour timeout when no matching self-hosted runner is available. [5]
To test network access, GitHub documents ./config.sh --check --url URL --pat TOKEN. The check prints PASS or FAIL for required services and writes details under _diag. Use a narrowly scoped temporary credential and never publish the token. GitHub warns against disabling TLS verification except for diagnosis because it removes transport privacy and integrity. [2]
Frequently asked questions
Is version 2.329.0 enough?
It is the minimum version for configuration and re-registration under this migration, not a permanent runtime target. Runners must also install each newer release within 30 days. Check the API’s version and deprecation data, then use the version GitHub currently offers to your organization. [1][4]
Will GitHub-hosted runners be affected?
No action is required for ordinary GitHub-hosted runners under this self-hosted runner enforcement notice. The affected software is the runner application that customers deploy and manage themselves. [1]
Does this apply to GitHub Enterprise Server?
GitHub says Enterprise Server is not impacted by this specific github.com enforcement rollout. Follow the compatibility guidance for your own GHES release instead of applying the cloud deadline blindly. [1]
What happens during the September 14, 16 and 18 brownouts?
GitHub plans temporary configuration and runtime blocking from 11 a.m. to 3 p.m. ET. Unsupported runners can fail to register and can stop executing jobs during those windows. Treat an intermittent queue or registration failure as an upgrade signal rather than waiting for September 25. [1]