GitHub Actions: Minimum version enforcement timeline for self-hosted runners 📆

[samus-aran]

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

%%{init: { "theme": "forest" }}%%
timeline
    title GitHub Enterprise Cloud with Data Residency - Rollout

    Week 1
           : June 29 — Config — runners on older versions cannot be registered

    Week 2
           : July 6 — Config — runners on older versions cannot be registered
           : July 8 — Config — runners on older versions cannot be registered

    Week 3
           : July 13 — Config — runners on older versions cannot be registered
           : July 15 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs
           : July 17 — Config — runners on older versions cannot be registered

    Week 4
           : July 20 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs
           : July 22 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs
           : July 24 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs

    Enforcement
           : July 31, 2026 — Full enforcement begins

Loading

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

%%{init: { "theme": "default" }}%%
timeline
    title GitHub Enterprise Cloud - Rollout

    Week 1
           : August 24 — Config — runners on older versions cannot be registered

    Week 2
           : August 31 — Config — runners on older versions cannot be registered
           : September 2 — Config — runners on older versions cannot be registered

    Week 3
           : September 7 — Config — runners on older versions cannot be registered
           : September 9 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs
           : September 11 — Config — runners on older versions cannot be registered

    Week 4
           : September 14 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs
           : September 16 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs
           : September 18 — Config + Runtime — runners on older versions cannot be registered and will not execute jobs

    Enforcement
           : September 25, 2026 — Full enforcement begins

Loading

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.

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 👇

Comment below if you have any concerns or questions on how to upgrade.