GitHub self-hosted runner version enforcement on September 29: Enterprise Cloud checks and upgrades

What changed on September 29?

GitHub's September 28, 2026 announcement moved full Enterprise Cloud self-hosted runner version enforcement from September 25 to September 29 and explicitly left requirements unchanged. It gives no exact hour, time zone, or enterprise-specific outcome, so the date alone cannot prove your pipeline was rejected.

The rule can affect registration, re-registration, and registered runners accepting or executing jobs. Identify ordinary Enterprise Cloud, Enterprise Cloud with Data Residency, or GitHub Enterprise Server before checking the applicable versions.

Which deployment does the correction affect?

For ordinary GitHub Enterprise Cloud, GitHub says full enforcement starts September 29. Enterprise Cloud with Data Residency began on July 31; this correction does not postpone its deadline. GitHub Enterprise Server, or GHES, is explicitly unaffected. Do not apply the cloud date to a self-managed Server instance.

These public dates are not evidence that a particular enterprise upgraded or passed account-level acceptance. Teams with mixed deployments should retain version and job evidence for each organization and runner pool.

Registration and job execution have different minimums

GitHub says runners below 2.329.0 cannot register or re-register. Registered runners have a higher, continually advancing job-execution minimum. An old runner can remain listed yet stop executing jobs. Do not describe 2.329.0 as a permanent universal runtime minimum.

GitHub's timeline says runners should update within 30 days of each new version release. Maintainers must refresh images or containers with automatic updates disabled. The deprecations API reports registration and runtime deprecation dates by runner version. Combine those results with organization settings and logs; one old registration audit event is not a current inventory.

Inventory the baseline before upgrading

You need the relevant repository, organization, or enterprise runner-management permission and access to the host or image. First inventory deployment, pools, host or image versions, automatic-update settings, last successful job, and current queue or failure state. Record registration failures separately from registered runners not accepting jobs.

Second, follow GitHub's September 3 announcement to query GET /actions/runners/deprecations/{version} at the applicable repository, organization, or enterprise scope. Inspect registration_deprecates_at and runtime_deprecates_at separately. If permissions, applicability, or UI results conflict, stop inferring and consult that deployment's documents and logs. Third, upgrade the package or base image through GitHub's runner update process, verify one noncritical pool, then roll out in batches and record versions before and after.

Fourth, have an authorized maintainer verify re-registration and a representative job actually being accepted and completed, including errors and queue time. This is a verification path, not an enterprise account accessed, upgrade executed, or successful test result obtained here.

Diagnose failures and choose a valid rollback

For registration failures, check deployment, version, and registration_deprecates_at. For persistent queues on registered runners, check runtime_deprecates_at, online state, labels, permissions, and logs. Network, container-pull, or proxy problems also fail pipelines; not every queue or failure is version enforcement. See Docker proxy and pull troubleshooting for that layer.

If an upgrade introduces failures, stop the rollout, retain the old image and logs, reproduce in an isolated pool, and consult GitHub documentation or support. Roll back only if the old version still meets registration and execution minimums. A rejected runner is not a dependable recovery target. Prefer a verified supported version and confirm new jobs complete. PRODUCT_FIT=NONE: changing IP cannot alter runner-version eligibility.

What still needs confirmation inside your enterprise?

The announcement does not expose your runner inventory, the rolling execution minimum's result for your organization, the exact enforcement hour, or each queued job's cause. To determine today's impact, match the official rule to your versions, deprecation results, and job logs.

This guide records official rules verifiable on September 29, 2026. Minimum versions continue to advance. When later announcements or results differ, recheck the current official timeline and substantively update this page rather than changing dates for superficial freshness.