What to know
- The revised schedule applies to GitHub Enterprise Cloud.
- Registration and job-execution minimums are different.
- Enterprise Server is outside the scope of this schedule change.
A changed date with unchanged requirements
GitHub announced on September 28 that full enforcement of its self-hosted runner version requirements on Enterprise Cloud would begin September 29. The notice distinguishes a registration minimum of version 2.329.0 from a higher minimum required to execute jobs. Existing registration therefore does not establish that an older runner can continue accepting work.
The schedule change does not apply to Enterprise Server. GitHub says enforcement for Enterprise Cloud with Data Residency had already begun in July. For operators reviewing the notice now, the September deadline has passed, so the immediate task is checking current fleet status and requirements rather than planning against the old date.
Inventory has to reach the machines that run jobs
A list of registered runners may not reflect the images from which replacement machines are created. Updating a running host can leave an autoscaling template unchanged, causing an older version to return when capacity expands. The inventory should connect active machines to their source images, provisioning scripts and update settings.
The same issue arises in infrequently used environments. A recovery runner or a machine reserved for a specialized build may remain idle during routine checks. It can fail only when a particular release requires it. A representative validation should exercise those paths rather than relying on the busiest jobs as evidence that the whole fleet is ready.
Operators also need to distinguish version failures from other reasons a job might remain queued. Labels, group access, capacity and network connectivity can produce similar visible symptoms. Recording the runner version and the relevant service response helps avoid changing unrelated configuration while diagnosing an enforcement problem.
Treat the runner as a maintained dependency
Byte Watchr’s analysis is that build infrastructure needs the same lifecycle discipline as application dependencies. A runner participates in the release chain and can hold access to source, package registries or deployment services. Its version should be visible in an inventory with a responsible owner and a tested update process.
A controlled rollout can validate the new runner against representative jobs before replacing a larger pool. The test should include the tools used by the workflow, its network access and any persistent state that the job assumes. If a rollback is needed, the team must also confirm that the older version remains accepted by the service.
The revised notice is a reminder that registration and operational eligibility are separate states. For affected organizations, the useful outcome is a fleet that can be recreated from current templates, checked automatically against supported versions and monitored for failures. That reduces dependence on discovering an outdated runner during a time-sensitive release.
Sources & further reading
Factual statements are grounded in the linked material. Interpretation and illustrative examples are Byte Watchr analysis. Vendor claims are identified as claims, rather than independent testing.
The event date records the source announcement or documented operation. The coverage edition groups recent developments and is separate from the publication date. Actual publication is recorded above.
Corrections policy · About this byline
