GitHub has moved the full enforcement date for self-hosted runner versions on GitHub Enterprise Cloud to September 29, 2026. The version requirements themselves have not changed, but teams operating self-hosted GitHub Actions runners now have a later date to prepare for the registration and runtime checks.
The change matters because version 2.329.0 is only the registration threshold. It is not a permanent version that a runner can remain on indefinitely. Runners must continue installing new releases within 30 days of publication or GitHub may stop queuing jobs for them.
What changed
According to GitHub’s September 28 changelog, full enforcement for standard GitHub Enterprise Cloud begins Tuesday, September 29, 2026. Runners below version 2.329.0 will not be able to register or reregister after enforcement begins.
The later date supersedes an earlier schedule. A June timeline listed September 25, 2026, for full enforcement on standard GitHub Enterprise Cloud. The newer September 28 announcement identifies September 29 as the moved date, so administrators should use that later primary-source date while recognizing that the earlier timeline remains in the documentation history.
The announcement affects GitHub Enterprise Cloud. GitHub Enterprise Server is not affected by this described enforcement-date change. GitHub Enterprise Cloud with Data Residency followed a separate schedule and had already reached full enforcement on July 31, 2026.
Version 2.329.0 is not the long-term runtime target
The most important operational detail is the distinction between registration and runtime support.
Version 2.329.0 is the minimum required for a runner to register or reregister after enforcement. However, an existing runner can still become too old to receive jobs. GitHub requires runners to install each new runner release within 30 days of publication. If a runner misses that window, GitHub may stop queuing jobs to it. GitHub may also pause job queuing when a critical security update is published until the update is applied.
This means there is no single permanent runtime version stated for September 29. The effective runtime requirement advances as new runner releases are published. A runner pinned at 2.329.0 might be able to register, but it will not remain a supported job-running target if it stops receiving updates.
Previously registered runners can therefore be affected even if their original registration succeeded. Outdated runners may stop receiving or executing workflow jobs, leave jobs queued, or cause workflows that target them to fail.
How administrators can check deprecation timing
GitHub’s supplied REST API documentation describes an organization-level endpoint for checking a runner version’s deprecation schedule:
GET /orgs/{org}/actions/runners/deprecations/{version}The endpoint returns information including the runner version and its runtime deprecation date. The documented example uses these headers:
Accept: application/vnd.github+json
Authorization: Bearer <YOUR-TOKEN>
X-GitHub-Api-Version: 2026-03-10The request requires authenticated organization-level administrative access. According to the REST API reference, classic personal access tokens and OAuth app tokens require the admin:org scope, while fine-grained tokens can use the organization’s read permission for self-hosted runners.
Administrators should treat this endpoint as an input to fleet monitoring rather than assuming it provides a complete inventory of every connected runner. The supplied documentation does not establish that the endpoint alone inventories every runner in an organization or provide a complete organization-wide alerting implementation.
Automatic updates do not remove the need for fleet management
Self-hosted runners automatically update when a job is assigned or, when idle, within a week of a new release. Operators that disable automatic updates must upgrade runners manually on a regular cadence.
That distinction is especially important for teams using immutable infrastructure or manually maintained runner pools. GitHub recommends updating the systems that create runners, not just the currently running machines. This includes installation scripts, virtual-machine images, container images, deployment automation, and cached runner templates.
Runner hosts also need to communicate with GitHub Actions, including outbound HTTPS access over port 443, as described in the self-hosted runner reference. The network requirement is a general runner requirement, not a new requirement introduced by this date change.
What you should do
- Inventory your runner fleet. Identify runners used by GitHub Enterprise Cloud organizations and determine which are below 2.329.0 or are not receiving regular updates.
- Upgrade before September 29. Bring runners to the latest supported version before the announced enforcement date rather than targeting only the 2.329.0 registration minimum.
- Review update settings. Confirm whether automatic updates are enabled. If they are disabled, establish and test a manual upgrade cadence that meets the rolling 30-day requirement.
- Update provisioning sources. Refresh installation scripts, VM and container images, deployment automation, and cached runner templates so replacement runners do not reintroduce an outdated version.
- Monitor deprecation schedules. Use the runner deprecation API where appropriate to retrieve registration and runtime dates and incorporate that information into fleet alerts.
- Verify connectivity and registration. Make sure runner hosts can reach GitHub Actions over outbound HTTPS and test the process used to register or reregister replacement runners.
The supplied installation documentation covers selecting an operating system and architecture, downloading and extracting the runner, configuring it with a time-limited token, optionally installing it as a service, and starting the runner. It does not provide a universal upgrade or rollback procedure for every installation model, so teams should validate their own deployment process rather than assume that one procedure applies to all runner environments.
Availability and operational caveats
This enforcement change is for GitHub Enterprise Cloud. It does not apply to GitHub Enterprise Server based on the supplied announcement. Data Residency customers have a separate timeline and had already entered full enforcement on July 31, 2026.
The exact runtime-supported runner version on September 29 is not specified in the supplied material because the runtime requirement changes as new releases become available. The concrete threshold provided is 2.329.0 for registration and reregistration; continuing to run jobs requires staying within the rolling update window.
GitHub does not describe this announcement as a vulnerability or exploit. The operational risk is workflow disruption if runners cannot register, are no longer eligible for jobs, or remain queued because their versions are outside the supported window.
