GitHub Actions runner enforcement: 24 August brownouts, 25 September cutoff

Summary. GitHub is resuming minimum version enforcement for self-hosted Actions runners. Full enforcement begins 25 September 2026 for GitHub Enterprise Cloud and began 31 July 2026 for GitHub Enterprise Cloud with Data Residency. Brownouts start 24 August 2026 and run 11:00 to 15:00 ET on published dates, first blocking registration of unsupported runners and then blocking job execution. Two separate requirements apply: a runner needs version 2.329.0 or later to configure or register, and it must install each new runner release within 30 days of publication to keep executing jobs. Missing either means runners fail to register or stop picking up jobs, and workflows targeting them stay queued or fail. GitHub Enterprise Server is not impacted at this time. The context is a backend rewrite: GitHub reported about 23 million Actions jobs per day in early 2024, 71 million per day by December 2025 and more than 120 million per day by June 2026, alongside a hosted-runner price cut of up to 39 percent on 1 January 2026 and a $0.002 per-minute Actions cloud platform charge.

The two requirements are not the same thing

Most teams read the announcement, see "2.329.0", pin their image to 2.329.0 and consider the work done. That fails.

GitHub's changelog states both rules explicitly. To configure or register a runner, it must be on version 2.329.0 or later, which is the minimum the new architecture needs to recognise the runner and let it connect. To continue executing workflow jobs, the runner must stay up to date by installing each new runner release within 30 days of its publication. GitHub's own wording is direct: "Version 2.329.0 is only the minimum required to register with the new platform and receive updates. It is not a permanent minimum version for running jobs."

Any release counts. Major, minor or patch, the 30-day clock restarts with each one. A runner pinned to 2.329.0 that never updates again will register successfully and then quietly stop picking up jobs. Separately, when a critical security update is published, GitHub Actions pauses job queuing to the runner until the update has been applied.

Requirement	Threshold	What breaks if missed	Auto-update covers it?
Registration minimum	2.329.0 or later	Runner cannot register or reregister	Yes, if it reached the service before
Job execution currency	each release within 30 days	Runner stops picking up jobs	Yes, if it can reach the update service
Critical security update	apply on publication	Job queuing paused until applied	Yes
Self-repository action references	2.336.0 or later	That composition feature is unavailable	Yes, once released
GitHub Enterprise Server	not impacted at this time	Nothing	Not applicable

Runners with auto-update enabled meet the 30-day requirement automatically, as long as they can reach the update service. That last clause is where air-gapped and egress-restricted fleets fail. A runner in a locked-down VPC with no route to GitHub's update endpoint has auto-update switched on and is still falling behind.

The brownout calendars

Brownouts are the free warning. Actions runs them ahead of each enforcement date, first intermittently blocking registration of unsupported runner versions, then expanding to also intermittently block job execution. All brownouts run 11:00 to 15:00 ET.

Week	Type	Dates (GitHub Enterprise Cloud)
Week 1	Config only	24 August
Week 2	Config only	31 August, 2 September
Week 3	Config, then Config plus Runtime	7 September, 9 September (runtime), 11 September
Week 4	Config plus Runtime	14, 16, 18 September
Enforcement	Full	25 September 2026

GitHub Enterprise Cloud with Data Residency ran the same pattern earlier, with brownouts from 29 June through 24 July and full enforcement on 31 July 2026. If you are on Data Residency, enforcement has already happened, and any runner still failing is failing for this reason.

Treat 9 September as the date that matters on the Cloud calendar. That is the first Config plus Runtime day, when outdated runners fail to register and also stop executing jobs. If your pipelines go strange between 11:00 and 15:00 ET that day and recover afterwards, you have your answer and 16 days to act.

Find the outdated runners

GitHub has added two things to help, and both have limits worth knowing before you rely on them.

The runner version is now exposed on the REST API for self-hosted runners, from API version 2026-03-10. That is the cleanest inventory source for a fleet you can enumerate.

# Org-level fleet inventory, sorted by version
gh api --paginate \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  /orgs/YOUR_ORG/actions/runners \
  --jq '.runners[] | [.name, .status, .os, .labels[].name] | @tsv' \
  | sort -k2

# Enterprise-level, if you have the scope
gh api --paginate \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  /enterprises/YOUR_ENTERPRISE/actions/runners

Enterprise owners can also audit which runner versions are registering by querying the audit log for three registration events: org.register_self_hosted_runner, repo.register_self_hosted_runner and enterprise.register_self_hosted_runner. Each includes the runner version.

The catch is stated plainly in GitHub's changelog: audit log events are recorded at registration time, which gives visibility into runners that are actively registering, but is not a complete inventory of all connected runners. A long-lived VM runner registered eighteen months ago and never restarted will not appear. For large fleets, query the audit log through its REST API rather than the UI.

Combine both sources. The API tells you what is connected now; the audit log tells you what has registered recently and at which version. The runners that appear in neither are the ones that will surprise you on 25 September.

GitHub also emits runtime job annotations when workflows run on outdated runners. Those annotations are already appearing on affected jobs, so a grep across recent workflow runs is a third, cheap signal.

Fix it by fleet type

The remediation differs sharply depending on how your runners are provisioned, and the effort is concentrated in exactly the places that feel safest today.

Fleet type	Where the stale version hides	Fix	Recurrence risk
Long-lived VMs, auto-update on	Egress rules blocking the update service	Open egress or upgrade manually	Low once egress is fixed
Long-lived VMs, --disableupdate	Manual cadence slipped past 30 days	Scheduled upgrade job, monthly at minimum	High, needs automation
Golden AMI or VM template	Baked-in runner binary in the image	Rebuild image, then recycle instances	High, every image rebuild
Container images	Pinned runner version in the Dockerfile	Bump and rebuild, redeploy	High, needs a version bump job
ARC on Kubernetes	Pinned runner image tag in Helm values	Update values, roll the scale set	Medium
Ephemeral runners	Base image, not the runner lifecycle	Rebuild the base image	Medium

GitHub's own instruction list is short and covers all of these: upgrade all self-hosted runners to the latest supported version, update installation scripts, VM images, container images and deployment automation, and recreate runners built from older cached images or templates.

That third item is the one teams forget. An organisation can upgrade every running runner today and reintroduce the old version tomorrow, because the Terraform module still references an AMI built in March. Fix the image pipeline, not just the instances.

The --disableupdate trap

Since February 2022 a runner started with --disableupdate will not perform an automatic software update when a newer version is available. That flag is popular in containerised and compliance-controlled fleets for good reasons: it stops a runner mutating itself mid-poll and keeps the image reproducible.

GitHub's guidance when it shipped that flag already carried the constraint: for compatibility with the GitHub Actions service, you need to manually update your runner within 30 days of a new runner version being available. Enforcement makes that documented-but-ignored line load-bearing.

If you use --disableupdate, you now need a scheduled job that checks the latest release and rebuilds. A monthly cadence is the floor, not the target, because a release published on day 29 of your cycle leaves you one day of margin.

ARC teams have an extra wrinkle

Actions Runner Controller 0.14.0, released 19 March 2026, added a capability specifically for this problem: ARC can fully stop autoscaling for a runner set when the runner configuration is outdated. When a runner exits with exit code 7, the controller switches off autoscaling for that runner set, which prevents stale runners from provisioning while a new configuration rolls out.

Read the caveat in the same release note carefully. GitHub states that this capability depends on a runner change, the exit code 7 behaviour, that will ship in a later runner release, and that because of the runner version support policy the feature will not become fully effective until two releases after the runner change ships.

For a platform team planning September, that means ARC's safety net may not be armed in time. Do not schedule the fleet upgrade on the assumption that ARC will halt bad scale sets for you. Verify the behaviour in your own cluster on your own runner version before you rely on it.

The same 0.14.0 release brought multilabel support for runner scale sets, which removes the need for a separate scale set per combination of operating system, hardware tier, network configuration and compliance zone. If your fleet fragmented into dozens of scale sets for that reason, the enforcement upgrade is a sensible moment to consolidate them, because you will be rolling every scale set anyway. Teams running ARC on a cluster that also needs a Kubernetes upgrade should sequence both together rather than rolling nodes twice; our Kubernetes 1.35 and containerd 2.0 migration guide covers that ordering.

Why GitHub is doing this

The enforcement is the tail end of a backend rewrite rather than a policy whim, and the scale numbers explain the urgency.

GitHub's December 2025 pricing note says the platform ran about 23 million jobs per day by early 2024 and that the existing architecture could not reliably support the growth curve. After the rewrite, all Actions jobs moved onto the new architecture, which handled 71 million jobs per day at that point, over three times where they started, with individual enterprises able to start seven times more jobs per minute than the previous architecture supported. By the June 2026 changelog that figure had grown again, to more than 120 million jobs per day. Old runner versions are incompatible with the updated infrastructure, so completing the migration means the old versions cannot stay.

The commercial side moved in the same period and is worth separating from the enforcement, because the two get conflated. On 1 January 2026 GitHub reduced GitHub-hosted runner prices by up to 39 percent, driven by roughly a 40 percent cut across runner sizes paired with a new $0.002 per-minute Actions cloud platform charge already folded into the listed hosted rates. The proposed application of that per-minute charge to self-hosted runners, originally set for 1 March 2026, was postponed on 15 December 2025 so GitHub could re-evaluate the approach. Public repositories remain free, and GitHub Enterprise Server pricing was not affected. GitHub reported 11.5 billion Actions minutes used in public projects in 2025, which it valued at about $184 million.

If your self-hosted fleet exists mainly to avoid hosted-runner bills, the 39 percent cut is worth re-running against your own usage before you spend engineering time keeping a fleet alive. Our cloud FinOps guide for Indian teams covers how to build that comparison honestly, including the operational cost most self-hosted business cases leave out.

The upgrade sequence

1. Inventory via the REST API and the audit log, on the same day, and reconcile the two lists.
2. Sort runners by provisioning method, not by team. The fix is per method.
3. Fix image pipelines first: AMIs, container images, Terraform modules, Ansible roles.
4. Roll a canary runner group and run a real workflow against it, not a hello-world job.
5. Check egress for every network segment that hosts runners, including the restricted ones.
6. Turn auto-update back on wherever policy allows, and put a monthly rebuild job everywhere it does not.
7. Watch the 9 September Config plus Runtime brownout as a live test, with 16 days of margin.
8. Add runner version to whatever dashboard your platform team actually looks at.

Step 4 deserves emphasis. A runner that registers is not a runner that runs jobs, and the two failure modes have different dates. Test both.

India-specific considerations

Two patterns show up repeatedly in Indian engineering organisations and both raise the risk here.

The first is the global capability centre CI fleet. A GCC running self-hosted runners inside a customer's restricted network, often with --disableupdate set for change-control reasons, is close to the worst case: manual cadence, restricted egress, and a change-approval process that does not move in 30-day cycles. If the runner upgrade needs a change ticket, raise it in August, not in the week of the cutoff. Teams measuring GCC delivery performance should treat CI availability as part of that picture; our GCC AI ROI measurement framework covers where pipeline reliability belongs in those metrics.

The second is the timezone arithmetic on the brownouts. The 11:00 to 15:00 ET window is 20:30 to 00:30 IST. For an India-based platform team, every brownout lands in the evening and crosses midnight, which is exactly when nobody is watching the pipeline dashboard and the on-call rotation is thinnest. Schedule someone to observe the 9 September window deliberately, or you will learn about it from a stalled release the next morning.

Teams on GitHub Enterprise Server for data-residency reasons are outside this change entirely, which is worth confirming rather than assuming, because organisations often run Enterprise Server for one business unit and Enterprise Cloud for another. The enforcement applies to github.com, including GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency.

While the fleet is being rebuilt, it is a reasonable moment to tighten what those runners are allowed to do. CI runners hold the widest credential set in most organisations, which is why they are the primary target of npm supply-chain attacks; our keyv worm containment runbook and the npm install script approval workflow cover the controls that belong on a rebuilt image.

FAQ

What is the exact deadline for self-hosted runner enforcement?

Full enforcement begins 25 September 2026 for GitHub Enterprise Cloud. GitHub Enterprise Cloud with Data Residency reached full enforcement earlier, on 31 July 2026. Brownouts on the Cloud calendar start 24 August 2026 and run in four weekly blocks, each between 11:00 and 15:00 Eastern Time on the published dates.

Is 2.329.0 enough to keep my runners working?

No. Version 2.329.0 is only the minimum required to register with the new platform. To keep executing jobs, a runner must install each new runner release within 30 days of publication. GitHub states that a runner pinned to 2.329.0 that never updates again will not pick up jobs, even though it registered successfully.

Does auto-update satisfy the 30-day requirement?

Yes, provided the runner can reach the update service. Runners in restricted network segments may have auto-update enabled and still fall behind, because the update never downloads. Check egress for every network segment hosting runners, not only the ones you expect to be restricted.

How do I find which runner versions I am running?

The runner version is available on the self-hosted runners REST API from API version 2026-03-10. Enterprise owners can also query the audit log for org, repo and enterprise registration events, each of which includes the version. Audit events are recorded at registration time, so they are not a complete inventory.

Is GitHub Enterprise Server affected?

No. GitHub's changelog states the change applies to github.com, including GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency, and that GitHub Enterprise Server is not impacted at this time. Organisations running both should confirm which business units sit on which platform before assuming exemption.

What happens to jobs targeting an outdated runner?

New runners may fail to register, existing runners may stop picking up or executing jobs, and workflows targeting unsupported runners may remain queued or fail. During brownouts these effects are intermittent and confined to the 11:00 to 15:00 Eastern Time window, which makes them easy to misdiagnose as flakiness.

Does ARC protect me from rolling out stale runners?

Partly, and possibly not in time. ARC 0.14.0 stops autoscaling for a runner set when a runner exits with exit code 7. GitHub states the capability depends on a runner change shipping in a later release and will not be fully effective until two releases after that. Verify it in your own cluster.

Should we move to GitHub-hosted runners instead?

It is worth recalculating. GitHub cut hosted runner prices by up to 39 percent on 1 January 2026, driven by about a 40 percent reduction across sizes plus a $0.002 per-minute platform charge already included in listed rates. The proposed self-hosted per-minute charge was postponed in December 2025 pending re-evaluation.

How eCorpIT can help

eCorpIT runs release engineering and CI/CD platform work for product teams and global capability centres, and fleet-wide runner upgrades are the kind of deadline that is easy to underestimate and expensive to miss. Our senior engineering teams handle runner inventory, image pipeline rebuilds, ARC upgrades and the egress and change-control work that usually blocks these migrations in regulated environments. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified. If your self-hosted fleet needs to be current before 25 September, talk to our platform engineering team, or read more about our release engineering and CI/CD platform service.

References

1. GitHub Actions: Minimum version enforcement timeline for self-hosted runners — GitHub Changelog, 12 June 2026.
2. GitHub Actions: Self-hosted runners can now disable automatic updates — GitHub Changelog, the --disableupdate flag and the 30-day rule.
3. Actions Runner Controller release 0.14.0 — GitHub Changelog, 19 March 2026.
4. Pricing changes for GitHub Actions — GitHub, December 2025, including the postponement note.
5. Actions Runner Controller 0.12.0 release — GitHub Changelog.
6. Actions Runner Controller release 0.13.0 — GitHub Changelog.
7. Self-hosted runners REST API — GitHub Docs.
8. Hosting your own runners — GitHub Docs.
9. actions/runner releases — the source of truth for the latest runner version.
10. actions/actions-runner-controller — ARC repository.
11. Actions Runner Controller documentation — GitHub Docs.
12. actions/scaleset — the Go client ARC now uses for the Actions service APIs.

Last updated: 4 August 2026.