By GitHub published a new enforcement timeline for self-hosted Actions runner minimum versions on June 12. The first brownout is June 29 — fifteen days from now. If your team deprioritized runner upgrades after March’s rollback, that reprieve is over.
What Changed on June 12
GitHub has been working to enforce a minimum runner version since late 2025. The original March 16, 2026 deadline was pulled at the last minute after v2.329.0 exposed kernel compatibility failures in legacy cgroup environments — the kind of failure that breaks thousands of CI pipelines overnight. GitHub paused, shipped patches in v2.330.x through v2.332.0, and gave teams more runway.
That runway ended on June 12. The new GitHub Changelog announcement brings firm deadlines and a published brownout schedule. A granular calendar signals operational readiness — GitHub is not pulling this one.
The Brownout Calendar
Brownouts are temporary enforcement windows from 11 AM to 3 PM ET where non-compliant runners face intermittent failures. Two tracks apply depending on your GitHub Enterprise plan.
GitHub Enterprise Cloud with Data Residency
Full enforcement: July 31, 2026
| Date | Type | What Breaks |
|---|---|---|
| June 29 | Config | Runner registration fails |
| July 6, 8 | Config | Runner registration fails |
| July 13, 15, 17 | Config + Runtime | Registration AND job execution fail |
| July 20, 22, 24 | Config + Runtime | Registration AND job execution fail |
GitHub Enterprise Cloud
Full enforcement: September 25, 2026
| Date | Type | What Breaks |
|---|---|---|
| August 24 | Config | Runner registration fails |
| August 31, September 2 | Config | Runner registration fails |
| September 7, 9, 11 | Config + Runtime | Registration AND job execution fail |
| September 14, 16, 18 | Config + Runtime | Registration AND job execution fail |
A Config brownout means old runners can’t reregister if they go offline. A Runtime brownout means jobs stop queuing to them entirely — your CI goes silent with no obvious error in your workflow file.
What Version You Actually Need
v2.329.0 is the registration floor. The current latest is v2.332.0. But 2.329.0 is not a permanent fixed minimum — it is the entry point into a rolling 30-day update requirement. Once your runner is on 2.329+, it must install each new release within 30 days or GitHub stops queuing jobs to it.
For most runners this is transparent: auto-update is on by default and runs before each job. The risk is runners where auto-update was explicitly disabled. Check your startup scripts and systemd units for the --disableupdate flag.
The Containerized Runner Problem
This is the failure mode most teams miss until a brownout surfaces it. If you run self-hosted runners via Docker or Actions Runner Controller (ARC) on Kubernetes, the runner binary is baked into your image and does not auto-update.
- Rebuild your Docker base image with runner ≥ v2.329.0 (current: v2.332.0)
- Upgrade ARC controller to v0.14.0 or higher
- Update your Helm chart or deployment manifests and redeploy
The runner releases page has the latest binaries and container images. GitHub maintains an official minimal runner container image tagged per release — use it as your base rather than pinning a tarball URL in your Dockerfile.
How to Audit Your Runners Now
Check runner versions in the GitHub UI under Settings → Actions → Runners at the repo or organization level. For a programmatic check across your fleet:
# List runners and versions for a repo
gh api repos/{owner}/{repo}/actions/runners --jq '.runners[] | {name: .name, version: .version, status: .status}'
# Org-level audit
gh api orgs/{org}/actions/runners --jq '.runners[] | {name: .name, version: .version, status: .status}'Flag anything below 2.329.0 as a hard blocker. For standard Linux runners, the update sequence is straightforward:
sudo ./svc.sh stop
curl -L -o actions-runner-linux-x64.tar.gz https://github.com/actions/runner/releases/download/v2.332.0/actions-runner-linux-x64-2.332.0.tar.gz
tar xzf ./actions-runner-linux-x64.tar.gz
sudo ./svc.sh startThe Security Case for Not Waiting
Beyond the deadline, older runners carry a real security risk. Since the March pause, runners stuck on pre-2.329 versions remain exposed to Runner-Escape vulnerabilities — where a malicious pull request in an ephemeral container can access host environment variables and SSH keys. Upgrading is not only a compliance exercise; it closes an attack surface that has been sitting open for three months.
GitHub has postponed this enforcement twice. The March pause trained teams to treat runner deadlines as negotiable. The June 12 brownout calendar suggests that posture has changed. June 29 is the first real test — and the safest way to validate your runners is to upgrade before that window, not during it.
Your Pre-June 29 Checklist
- Run the API audit above and identify all runners below v2.329.0
- Check startup scripts for
--disableupdateflags on all registered runners - If using containerized runners: rebuild images with v2.332.0, upgrade ARC to v0.14.0+, redeploy
- Verify each runner registers successfully after update — do not assume it worked
- Bookmark the enforcement timeline — brownout dates are in the table above
The full enforcement dates are July 31 for GHEC Data Residency and September 25 for GHEC. Both tracks start their brownout sequence within the next two weeks. Get your runners current before the calendar forces the issue.
