GitHub Actions Self-Hosted Runner Enforcement Is Active: How to Check Your CI Before Jobs Stop

What changed with GitHub Actions self-hosted runners in September 2026?

GitHub now enforces minimum software versions more strictly for self-hosted runners on GitHub Enterprise Cloud. Full enforcement began on September 29, 2026, which means the version installed on a self-hosted runner is now an operational requirement rather than something that can be ignored indefinitely.

A runner can still have a working machine, network connection, and service process while becoming too old to receive GitHub Actions work. That distinction is important because the server itself may appear healthy while workflow jobs remain queued or stop reaching it. When CI suddenly stops moving, the installed runner version now belongs near the top of the troubleshooting list.

Which GitHub Actions self-hosted runner versions can stop working?

GitHub states that self-hosted runners below version 2.329.0 cannot register or re-register on GitHub Enterprise Cloud. That is the registration requirement, but it is not the only version rule that matters.

Already registered runners also need to remain above GitHub's runtime support threshold for executing workflow jobs. That threshold is separate from the registration floor and can move as GitHub releases newer runner versions. A runner that registered successfully in the past can therefore become too old to continue receiving workflow work later.

The practical approach is to maintain a runner update process rather than treating one upgrade as a permanent solution. Runner software has to keep moving with the GitHub Actions service, particularly in environments where runners are created automatically from reusable images.

How to check GitHub Actions self-hosted runner versions

The first task is to create a simple inventory of the self-hosted runners currently in use. For a small setup, registered runners can be reviewed in GitHub under Settings → Actions → Runners. For organizations managing more runners, GitHub's REST API is more practical because runner information can be collected centrally and includes the installed version.

The inventory does not need to become a large monitoring project. A small table showing runner name, installed version, update method, and current status is enough to expose whether old software is still deployed or whether some runners have no clear maintenance path.

The important result is visibility. Self-hosted runners should not exist in production without a clear answer to which version is installed and how that version will be updated when GitHub changes the supported range.

What happens when a GitHub Actions self-hosted runner is outdated?

An outdated runner can fail in more than one way, which is why the problem can be confusing during an incident. A registration problem, a runtime compatibility problem, and a general machine problem can all appear as unavailable CI capacity even though they have different causes.

Runner registration can fail

A runner below the registration minimum cannot newly register or re-register. This can become visible after a machine is replaced, a runner is recreated, a VM or container image is redeployed, or registration is attempted again after configuration changes. A runner image that worked previously can therefore begin failing during a later deployment if the bundled runner package has become too old.

Workflow jobs can stop reaching an existing runner

A runner can already be registered and still fall below GitHub's runtime support requirement later. In that situation, the machine may still be online and the runner service may still exist, but GitHub can stop assigning workflow jobs to it. The operating system being healthy does not guarantee that the runner software is still compatible with the service.

GitHub Actions jobs can remain queued

When no compatible runner is available, a workflow may remain queued instead of immediately presenting the runner version as the obvious cause. That can make the incident look like a wider CI or infrastructure problem. Checking the runner version alongside connectivity, labels, status, and machine health can narrow the cause much faster.

How to update GitHub Actions self-hosted runners

GitHub self-hosted runners update automatically by default, so a normal long-running runner may already have the maintenance mechanism it needs. The first check is whether those automatic updates are actually completing. GitHub documents update activity in the runner logs, including files in the _diag directory, which can help show whether an update succeeded or whether the runner has fallen behind.

Some environments intentionally disable automatic runner updates because the runner software is controlled through a machine image, container image, or another repeatable deployment process. In that setup, updating the runner means updating the deployment source rather than changing one machine by hand.

GitHub states that runners with automatic updates disabled must be updated within 30 days of a new runner release. If a critical security update is required, GitHub can stop queueing jobs until that update is installed. The important operational decision is therefore to know whether a runner follows GitHub's automatic update path or an internal image and deployment lifecycle.

Does GitHub Actions runner version enforcement affect GitHub Enterprise Server?

This specific September 2026 enforcement change applies to GitHub Enterprise Cloud. GitHub states that GitHub Enterprise Server is not affected by this enforcement change, so the September 29 enforcement schedule should not be copied directly onto a GitHub Enterprise Server environment.

That does not mean GitHub Enterprise Server runners never need updates. It means this particular GitHub Enterprise Cloud policy and deadline are not the correct source for determining Enterprise Server runner compatibility. The GitHub deployment type should therefore be confirmed before applying a version requirement or troubleshooting against the wrong support policy.

How to check GitHub Actions runner version deprecation dates

GitHub provides a REST API for runner-version deprecations, allowing registration and runtime end-of-life information to be checked for a specific runner version. That makes it possible to build a lightweight internal check instead of relying on a version number copied from an older announcement.

For an organization, the endpoint follows this form:

GET /orgs/{org}/actions/runners/deprecations/{version}

GitHub also provides a repository-level version of the endpoint. Using current deprecation information is a better long-term approach because the supported range can move over time. Instead of treating 2.329.0 as a permanent target, CI maintenance can identify runner versions approaching their registration or runtime deadline.

The main rule for GitHub Actions self-hosted runners

A self-hosted runner should not be installed once and forgotten. GitHub Actions continues to evolve, and the runner software has to remain compatible with the service that assigns workflow jobs.

For a small setup, healthy automatic updates may be enough. For image-based or larger runner fleets, the runner version needs to become part of the normal deployment and monitoring process so an outdated package does not first become visible when an important workflow stops moving.