The distinction that matters for a CI team is between registering a runner and receiving workflow jobs. Version 2.329.0 is the minimum for the first. It is not a permanent minimum for the second. A runner can remain registered and still become too old to execute jobs.
The registration floor is 2.329.0
GitHub says a self-hosted runner older than 2.329.0 cannot register or re-register under the new Enterprise Cloud architecture. That is a check for new installations and rebuilt runners. It also matters if a deployment pipeline repeatedly creates ephemeral runners from a cached image: updating one live machine will not repair the template that creates the next old one. GitHub explicitly tells operators to update installation scripts, VM images, container images and deployment automation in its enforcement guidance.
The June guidance also states what 2.329.0 does not mean. It is a registration floor, not a promise that a runner pinned at that version will keep processing jobs. Treating a successful registration as the entire migration check misses the moving requirement below.
The job-execution floor moves with runner releases
To keep receiving work, a runner must install each new runner release within 30 days of that release becoming available. If it does not, GitHub says the Actions service will stop queuing jobs to that runner. A critical security release can pause queuing until the update is applied even sooner. This makes “at least 2.329.0” an insufficient runtime policy for a long-lived fleet.
Automatic runner updates are enabled by default. A fleet that disables them needs a recurring update process, while a fleet that expects automatic updates still needs to verify that its runners can reach the update service. GitHub distinguishes the fixed registration threshold from the version-dependent runtime deadline in its 28 September correction. It does not publish one permanent runtime version number in that notice.
Check the affected runner before rebuilding the fleet
An organization administrator can use GitHub's self-hosted runner REST API to list organization runners at GET /orgs/{org}/actions/runners. The returned records include the runner's version, status, busy state and labels. The endpoint requires appropriate organization access; a public repository page will not reveal a private fleet. First identify the particular runner or image serving the queued workflow and record its installed version.
- Check registration: if a new or recreated runner is below 2.329.0, update the binary and the image or installation script that supplies it.
- Check runtime support: use the organization runner-version deprecation endpoint for the installed version. Its response reports the relevant end-of-life schedule; use that response rather than assuming 2.329.0 is current enough.
- Verify assignment after updating: confirm that the runner is online, that its labels match the workflow's
runs-ontarget, and that a fresh job is assigned. A queued job alone cannot identify which of those checks failed.
The deprecation API also exists at repository and enterprise scope, according to GitHub's September API announcement. Its documentation examples are illustrative responses, not evidence about any reader's fleet. This article has not tested or inspected an affected organization.
Node 24 is a separate migration
GitHub removed Node 20 for JavaScript actions on 23 September. Action maintainers must release Node 24-compatible actions, and workflow owners should use supported action versions. That change can break an action after a runner receives a job. It should not be confused with the runner-version gates that prevent registration or job assignment. GitHub also says Node 24 excludes macOS 13.4 and earlier and does not officially support ARM32 self-hosted runners.
The 29 September date applies to GitHub Enterprise Cloud on github.com. GitHub Enterprise Cloud with Data Residency already began enforcement on 31 July, while GitHub Enterprise Server is outside this change, according to the current GitHub notice. If a runner is current and online but jobs still queue, investigate labels, policy and service status rather than attributing every queue to the version rule. The same symptom-first discipline matters in other software failures; our Chrome localhost-versus-printer guide shows how two separate gates can produce superficially similar errors.
