GitHub Actions Self-Hosted Runner Enforcement Starts September 29: Update Before Jobs Stop

According to GitHub's changelog, the enforcement date for GitHub Actions minimum version requirements on self-hosted runners for GitHub Enterprise Cloud has been pushed back. The change ships Monday, September 28, 2026, with full enforcement beginning Tuesday, September 29, 2026, replacing the previously announced date. The replaced date was September 25. GitHub's June 12 timeline had said "GitHub Enterprise Cloud: Full enforcement begins September 25, 2026."

So the grace period is four days, and GitHub announced it one day before it ends. That is enough time to finish an upgrade that is already underway. It is not enough time to start one from scratch.

What changed and what didn't​

Only the date changed. The rules are the same as before:

• Registration floor: runners below version 2.329.0 can't register or reregister
• Job-execution floor: runners below the higher minimum required to execute jobs will stop running jobs even if already registered
• Scope: This only affects GitHub Enterprise Cloud, not GitHub Enterprise Server.
• Data Residency customers: Enterprise Cloud with Data Residency already began enforcement on July 31, 2026. That date is not affected by this change.

Summary: Enterprise Cloud now has until Tuesday, September 29. Data Residency tenants are already under enforcement, and GitHub Enterprise Server is not affected.

Two version numbers, not one​

Many admins will see "2.329.0" and assume that version keeps a runner working. It doesn't. That number only controls whether a runner can register.

GitHub's June timeline says 2.329.0 is the minimum needed to register with the new platform and receive updates. It is not a permanent minimum for running jobs. To keep executing jobs, a runner must install each new runner release within 30 days of its publication. The effective floor for job execution therefore rises every time GitHub ships a runner release. That includes major, minor and patch releases.

GitHub also says:

• A runner pinned at 2.329.0 that never updates will stop picking up jobs.
• If a runner goes 30 days without installing an available update, the service stops queuing jobs to it.
• When GitHub publishes a critical security update, it can pause job queuing to a runner until that update is installed.

GitHub has been explaining this distinction for months. In March, an editor's note on its changelog clarified that runners on versions older than the latest release by more than 30 days (currently v2.330.0 and below) will be rejected from executing workflows as part of our standard runner deprecation process. The runner versions quoted there are six months old now. What still applies is that the job-execution floor was already above 2.329.0 back then.

Auto-update handles the 30-day rule on its own, as long as the runner can reach GitHub's update service. The risk sits with runners that have auto-update turned off. GitHub warned that runners with auto-update disabled (including those managed by ARC with disableUpdate=true) must be manually updated to a supported version. ARC is Actions Runner Controller, the Kubernetes-based runner manager. If your ARC setup pins runner images, it needs attention first.

Summary: 2.329.0 lets a runner register. Staying current within 30 days of each release lets it keep running jobs. You need both.

A deadline that has moved several times​

This is not the first delay. The enforcement effort goes back to late 2025:

DevOps.com covered the June relaunch and noted that it followed a rocky start that included multiple delays and a temporary pause earlier this year. The outlet also described the stakes as a potential full stop on CI/CD pipelines — not a warning message.

It would be easy to read the history of delays as a sign that this date will slip too. We think that would be a mistake. This latest change moves the date four days forward. It is not a pause, and GitHub's own wording is that full enforcement "now begins" September 29.

Why GitHub is doing this​

GitHub says this is part of rebuilding the backend of GitHub Actions. According to GitHub, the team began rearchitecting the backend services that power job execution and runner communication in early 2024. The rebuilt platform now handles over 120 million jobs per day — more than three times the pre-migration volume — and lets enterprises start seven times more jobs per minute than before. Older runner versions can't work with the new infrastructure. Once every runner has moved to it, GitHub stops supporting those versions.

That reasoning holds up. Some admins will still be annoyed that GitHub moved the date with one day's notice, especially those who scheduled change windows around September 25.

What failure looks like​

GitHub's June notice lists three symptoms for organizations that miss the deadline:

1. New runners may fail to register with Actions.
2. Existing runners may stop picking up or executing jobs.
3. Workflows targeting unsupported runners may remain queued or fail.

The third symptom is the hardest to diagnose. A job stuck in "Queued" doesn't produce an obvious error, so it can look like an unrelated capacity problem. If your pipelines start stalling on Tuesday, check runner versions early in your investigation.

A practical checklist before Tuesday​

This sequence is built from GitHub's documented APIs and guidance. GitHub does not provide a ready-made fleet-wide alerting tool.

1. Take inventory​

GitHub's REST API for self-hosted runners includes a "list self-hosted runners for an organization" endpoint (GET /orgs/{org}/actions/runners). Its documented response includes each runner's version, status, busy state and labels. The endpoint needs organization admin access. Classic tokens need the admin:org scope. Fine-grained tokens need read access to the organization's "Self-hosted runners" permission.

2. Check deprecation dates for each version​

The new runner-version deprecation API is the main new tool here. GitHub documents two lookup routes:

• GET /orgs/{org}/actions/runners/deprecations/{version}
• GET /repos/{owner}/{repo}/actions/runners/deprecations/{version}

The organization route requires org admin access. Classic tokens need admin:org, and fine-grained tokens need organization "Self-hosted runners" read access. The repository route requires repository admin access. Classic tokens need repo, and fine-grained tokens need repository "Administration: read". The response returns the runner version plus registration and runtime end-of-life dates where they apply. GitHub's documentation example shows version 2.300.0 with runtime_deprecates_at set to 2026-09-01T00:00:00Z.

To automate this, loop over the unique versions from step 1, query each one, and send an alert for anything with a runtime deprecation date that is close or already past. GitHub describes the API as suitable for building exactly that kind of alert.

3. Check the audit log for registration events​

Enterprise owners can query audit log events that record the runner version:

• org.register_self_hosted_runner
• repo.register_self_hosted_runner
• enterprise.register_self_hosted_runner

These events are only recorded when a runner registers. They show runners that are registering now, not every runner that is already connected. GitHub suggests using the audit log REST API instead of the web UI for large fleets.

4. Find where old versions come from​

A runner you upgraded today can come back on an old version tomorrow if its source image is stale. GitHub's guidance is to:

• Update installation scripts, VM images, container images and deployment automation.
• Recreate any runners built from older cached images or templates.
• Confirm that auto-update is enabled and that runners can reach the update service. Where auto-update is off on purpose, set a regular manual update schedule that stays well inside the 30-day window.

5. Test each label​

Community guidance on this topic makes a useful point: runner version enforcement only answers whether the machine can register and accept work; it does not validate every workflow dependency. After upgrading, run a test job against each label that production workflows target. Confirm it lands on an upgraded machine and not on an older one that shares the same labels.

Summary: Inventory your runners, check each version's deprecation dates, fix the images that create runners, and test every label. Try to finish before the September 29 enforcement start.

Who needs to act, and who doesn't​

• GitHub Enterprise Cloud with self-hosted runners: Act now. The deadline is Tuesday.
• Enterprise Cloud with Data Residency: You have been under enforcement since July 31. If jobs are stalling, this is a likely cause.
• GitHub Enterprise Server: Not affected by this change. Follow the runner compatibility guidance for your GHES release.
• GitHub-hosted runners only: Nothing to do. GitHub manages those machines.

Windows build servers are no exception. GitHub publishes runner binaries for Windows x64 alongside Linux and macOS, and the same rules apply to all of them. A Windows runner kept on an old version because an admin turned off auto-update is exactly the kind of machine this enforcement is meant to catch.

The bottom line​

GitHub gave Enterprise Cloud four more days but no change to the rules. After many months of warnings, the deadline is now Tuesday, September 29. The version that matters for keeping jobs running is not 2.329.0 but the current release minus 30 days. If your runners auto-update and can reach GitHub's update service, you are probably fine. If you pinned versions or built runners from old images, you should check them before Tuesday.