GitHub Actions is resuming enforcement of version requirements for self-hosted runners on github.com and GitHub Enterprise Cloud with Data Residency. This change is part of a broader effort to rebuild the core of GitHub Actions to increase our reliability and availability. In early 2024, the Actions team began rearchitecting the backend services that power job execution and runner communication—a foundational investment in the reliability, availability, and performance our customers depend on. The new architecture now handles over 120 million jobs per day, more than three times the volume before the migration, and enables enterprises to start seven times more jobs per minute than previously possible. Resuming version enforcement is the next step in completing this migration: as all runners move onto the new platform, older runner versions that are incompatible with the updated infrastructure can no longer be supported.

There are two requirements that together keep a runner compatible with the new platform:

  • To configure or (re)register a runner: The runner must be on version 2.329.0 or later. This is the minimum version required for the new architecture to recognize the runner and allow it to connect.
  • To continue executing workflow jobs: The runner must stay up to date by installing each new runner release within 30 days of its publication. This is an existing requirement but was not consistently enforced in some cases.

Version 2.329.0 is only the minimum required to register with the new platform and receive updates. It is not a permanent minimum version for running jobs. The effective minimum version for job execution moves forward over time as new runner releases are published.

Runners with auto-update enabled meet the 30-day requirement automatically, as long as they can reach the update service.

Runners with auto-update disabled must be upgraded manually on a regular cadence. Meeting the registration minimum on its own isn’t enough. A runner pinned to 2.329.0 that never updates again will not pick up jobs.

Any release of the software, whether a major, minor, or patch version, qualifies as an available update. If the runner is not updated within 30 days of an update being available, the GitHub Actions service will stop queuing jobs to it. Additionally, when a critical security update is published, GitHub Actions will pause job queuing to the runner until the update has been applied.

Enforcement timeline

Ahead of each enforcement date, Actions will run temporary brownouts. Brownouts will start by intermittently blocking registration of unsupported runner versions, then expand to also intermittently blocking job execution on unsupported runners. These brownouts help you identify outdated runners and take action before enforcement begins.

GitHub Enterprise Cloud with Data Residency: Full enforcement begins July 31, 2026.

GitHub Enterprise Cloud: Full enforcement begins September 25, 2026.

After each enforcement date:

  • Self-hosted runners below the minimum version required for registration (e.g., runners older than 2.329) won’t be able to register or reregister.
  • Existing runners below the minimum version required to execute workflow jobs (i.e., a higher version than the registration minimum) will stop running workflow jobs, even if they were previously registered.

All brownouts run from 11:00 AM to 3:00 PM ET on the dates listed below.

GitHub Enterprise Cloud with Data Residency

Enforcement date: July 31, 2026

Week Cadence Type Outcome Dates
Week 1 1 day Config Runners on older versions cannot be registered June 29
Week 2 2 days Config Runners on older versions cannot be registered July 6, July 8
Week 3 3 days Config, and Config + Runtime Runners on older versions cannot be registered; on the Config + Runtime day, they also will not execute jobs July 13 (Config), July 15 (Config + Runtime), July 17 (Config)
Week 4 3 days Config + Runtime Runners on older versions cannot be registered and will not execute jobs July 20, July 22, July 24
Enforcement — — Full enforcement begins July 31, 2026

GitHub Enterprise Cloud

Enforcement date: September 25, 2026

Week Cadence Type Outcome Dates
Week 1 1 day Config Runners on older versions cannot be registered August 24
Week 2 2 days Config Runners on older versions cannot be registered August 31, September 2
Week 3 3 days Config, and Config + Runtime Runners on older versions cannot be registered; on the Config + Runtime day, they also will not execute jobs September 7 (Config), September 9 (Config + Runtime), September 11 (Config)
Week 4 3 days Config + Runtime Runners on older versions cannot be registered and will not execute jobs September 14, September 16, September 18
Enforcement — — Full enforcement begins September 25, 2026

What you’ll see before enforcement

To help you prepare, Actions will provide:

  • Runtime job annotations when workflows run on outdated runners.
  • APIs and tooling to help you identify unsupported runner versions and plan upgrades. To start, we have added the runner version to the REST API.

If you don’t upgrade your self-hosted runners before enforcement:

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

Identify runners that need upgrading

If your organization uses GitHub Enterprise Cloud or GitHub Enterprise Cloud with Data Residency, enterprise owners can audit which runner versions are currently registering by querying the audit log for the following runner registration events, each of which includes the runner version:

  • org.register_self_hosted_runner: Registration events scoped to an organization
  • repo.register_self_hosted_runner: Registration events scoped to a repository
  • enterprise.register_self_hosted_runner: Registration events scoped to the enterprise

Note: Audit log events are recorded at registration time. This gives you visibility into runners that are actively registering, but is not a complete inventory of all connected runners. For large fleets, consider querying via the audit log REST API rather than the UI.

What you need to do

To avoid disruption to your CI/CD workflows:

  • Upgrade all self-hosted runners to the latest supported version.
  • Update installation scripts, VM images, container images, and deployment automation.
  • Recreate runners you’ve built from older cached images or templates.

Note: This change applies to github.com, including GitHub Enterprise Cloud and GitHub Enterprise Cloud with Data Residency. GitHub Enterprise Server isn’t impacted at this time.

Upgrading your self-hosted runners ahead of time is the best way to ensure uninterrupted use of Actions. For more information, see the self-hosted runner documentation.

Share your feedback

Join the GitHub Community to share your feedback or for any questions.