GitHub Enterprise Cloud stopped registering self-hosted runners below version 2.329.0 today, and any runner already registered below the execution-version floor stops picking up jobs at the same time. GitHub's changelog post on the moved enforcement date puts it plainly: "full enforcement now begins Tuesday, September 29, 2026." GitHub's June announcement said September 25; the deadline moved once already, from September 25 to September 29, in a post published the day before enforcement began. If nobody has checked your self-hosted runner minimum version since that first announcement, today is the day to check it.
What changed on September 29, 2026
Two things happened at once. Runners below 2.329.0 lose the ability to register or reregister at all: "Self-hosted runners below version 2.329.0 won't be able to register or reregister," in GitHub's own wording. Separately, any runner that was already registered but sits below the execution-version floor, a higher and moving target, stops being handed jobs, even while it still shows up as registered in the UI.
The scope is narrower than "every GitHub customer." GitHub says it plainly: "This shift only affects GitHub Enterprise Cloud. GitHub Enterprise Server isn't impacted." Running GHES instead of GHEC means none of today's deadline touches you.
And the date itself hasn't been stable. This is the second time GitHub has moved it, which the timeline further down covers in order.
Why this hits self-hosted runners specifically
A self-hosted runner faces two separate floors, not one. The registration floor, 2.329.0, is the version GitHub's newer registration architecture needs to recognize a runner and let it connect at all. GitHub hasn't said that number will change. The execution floor is different: it moves forward as GitHub ships new runner releases, and a runner has 30 days after each release to update before GitHub stops queuing jobs to it. A critical security release can trigger that same pause immediately, without waiting out the 30 days.
That's why a runner can be fully registered, visible in the UI, checked once against 2.329.0 and forgotten, and still stop running jobs today. Clearing the registration bar once doesn't keep a runner eligible. It has to keep updating.
Scope, again: this covers GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. GitHub Enterprise Server isn't affected, and GitHub hasn't announced a separate timeline for it.
GitHub Actions changed something else this quarter too. A separate change to how the Actions API reports workflow-run counts means the REST API now returns "2,500+" instead of an exact number once a workflow-run query matches more than 2,500 records, a different mechanism covered in HighCircl's Platform and language release notes: what breaks and what to fix.
How to check and upgrade your runners
Five steps, in order, cover a fleet of any size.
1. Inventory every self-hosted runner's current version
Pull the version for every self-hosted runner registered to the org or repo, not just the ones you already suspect are old. The runner-detail endpoint in GitHub's REST API, GET /orgs/{org}/actions/runners/{runner_id}, returns a runner's current version alongside its name, status and labels. The GitHub UI shows the same version column under an org's or repo's runner settings, which is fine for a handful of runners but slow past a few dozen.
2. Check each version against GitHub's deprecation API
A version number alone doesn't say whether a runner is compliant, since the execution floor keeps moving. GitHub's version-deprecations endpoint, GET /orgs/{org}/actions/runners/deprecations/{version}, answers that directly: pass it a runner version and it returns registration_deprecates_at and runtime_deprecates_at, the exact dates that version stops being allowed to register and stops being allowed to execute jobs. Run every distinct version in your fleet through this endpoint once rather than trusting last month's check.
3. Confirm auto-update is enabled, or plan manual upgrades
Self-hosted runners update automatically by default, according to GitHub's documentation on managing self-hosted runners, and auto-update can be turned off. Any runner running with --disableupdate, or any image-based deployment that bakes a runner binary into a container or AMI, needs a manual upgrade process instead, since auto-update never fires there in the first place. If nobody owns that process today, it's usually the engineer who owns CI/CD pipeline maintenance who ends up building it, whether or not that's officially their job.
4. Upgrade any runner below 2.329.0 immediately
Anything still below 2.329.0 can't currently register, so this stops being a scheduling decision. Pull the current release from the self-hosted runner's releases page and install it the way you'd install any runner update: stop the runner service, replace the binary or image, restart, and confirm it comes back online. Don't guess the version from a cached download link or a base image built months ago; check the releases page directly.
5. Re-verify registration and job pickup after upgrading
Query the runner again through the same API call from step 1, or check the UI, and confirm the version shown has actually changed. Then watch it pick up a real job rather than trusting a green "online" status by itself. A runner can sit registered and idle without ever successfully claiming a job if something else is misconfigured underneath the version fix.
The full enforcement timeline
This is the second time GitHub has moved this deadline. The first came in March.
GitHub paused the original enforcement attempt in March 2026. GitHub's changelog post announcing the pause called off what had been scheduled for March 16, 2026, so it could work through a smoother transition before enforcing the version floor.
Three months later, GitHub published a full brownout schedule. GitHub's June enforcement timeline set 2.329.0 as the registration floor, explained that the execution floor would keep moving forward as new runner releases ship, and laid out two separate dates: GitHub Enterprise Cloud with Data Residency would reach full enforcement on July 31, 2026, already in effect, and standard GitHub Enterprise Cloud would follow on September 25, 2026. That post also pointed enterprise owners to their audit logs, where runner registration events show which versions are actually connecting.
September 25 came and went differently than planned. GitHub moved standard GHEC's date again, to September 29, in a post published the day before enforcement began. A team that read the June timeline, set a reminder for September 25, and stopped checking would have walked in four days early on paper and exactly on time in practice, since nothing broke until today.
This runner deadline lands within the same month as the Node 24 runtime cutover that forced its own runner check and GitLab's own coordinated security release a week earlier, worth checking together if your team runs both platforms.
FAQ
Does this affect GitHub Enterprise Server?
No. GitHub's own confirmation of the scope is direct: GitHub Enterprise Server isn't impacted by any of this, brownouts or full enforcement. If your org runs GHES, neither the registration floor nor the execution floor applies, and GitHub hasn't announced a separate GHES timeline.
Is 2.329.0 the permanent minimum version?
For registration, yes, at least for now, since that's the version GitHub's newer runner architecture recognizes. For execution, no. The execution floor moves forward as GitHub ships new runner releases, so a runner sitting on exactly 2.329.0 and never updating again will eventually fall behind the execution floor even while it still clears the registration minimum.
What happens if a runner doesn't update within 30 days?
GitHub stops queuing jobs to it. Runners are expected to update within 30 days of each new release, and one that misses that window keeps its registration but stops receiving work until it catches up. A critical security release can force that same pause immediately, without waiting for the 30-day window to run out.
Does GitHub Enterprise Cloud with Data Residency have the same deadline?
No, it already passed. GitHub Enterprise Cloud with Data Residency reached full enforcement on July 31, 2026, two months before standard GitHub Enterprise Cloud's September 29 date. If your org uses Data Residency, this deadline isn't new; it's been in effect for two months.