GitHub Actions Runner Enforcement Starts June 29

GitHub is pulling the trigger on minimum version enforcement for self-hosted Actions runners. The first brownout hits June 29, 2026, with full enforcement following on July 31 for GHEC Data Residency customers and September 25 for standard GHEC. If you're running self-hosted runners on anything older than v2.329.0, you've got about two weeks to fix it before your CI starts breaking intermittently.

This isn't new. GitHub initially announced the minimum version requirement back in February 2026 with a March enforcement date, then paused it. Now they've published a detailed enforcement timeline with brownout dates, and this time there's no ambiguity about what happens or when.

Why this is happening

GitHub has been rebuilding the core backend of Actions since early 2024. The rearchitected platform now handles over 120 million jobs per day (three times the pre-migration volume) and lets enterprises start seven times more jobs per minute. Older runner versions aren't compatible with the new infrastructure, and continuing to support them holds back the migration.

Version 2.329.0 (released October 15, 2025) is the minimum required for a runner to register with the new backend. But registration is only half the story.

Two requirements, not one

The enforcement has two separate teeth, and the second one is the one most teams will miss:

1. Registration minimum. Runners below v2.329.0 can't register or re-register with the Actions service. This is the hard floor for connecting to the new backend.
2. 30-day update window. Once registered, the runner must install each new release within 30 days of publication. Miss that window and the Actions service stops queuing jobs to it. Any release counts: major, minor, or patch.

This means a runner pinned at v2.329.0 with auto-update disabled will register successfully but stop picking up jobs within a month. The effective minimum version for job execution rolls forward continuously. If you've got --disableupdate set (common in containerized and ARC deployments), you'll need a rebuild/redeploy cadence that keeps pace with runner releases.

There's also a fast path for critical security updates. When GitHub publishes a security release, the Actions service pauses job queuing to the affected runner immediately, outside the normal 30-day window. No brownout, no grace period.

The brownout schedule

All brownouts run from 11:00 AM to 3:00 PM ET on their scheduled dates. The escalation pattern is deliberate: it starts with registration blocks only ("Config"), then adds job execution blocks ("Config + Runtime") in later weeks.

GHEC with Data Residency (enforcement: July 31)

• June 29 — Config only. Registration intermittently blocked for outdated runners. This is the warning shot.
• July 6, 8 — Config only. Two days of registration blocks.
• July 13, 15, 17 — Mixed. Config blocks on the 13th and 17th; Config + Runtime on the 15th (jobs won't execute).
• July 20, 22, 24 — Config + Runtime on all three days. Registration and job execution both blocked.
• July 31 — Full enforcement. Permanent block on outdated runners.

Standard GHEC (enforcement: September 25)

• August 24 — Config only.
• August 31, September 2 — Config only.
• September 7, 9, 11 — Config on the 7th and 11th; Config + Runtime on the 9th.
• September 14, 16, 18 — Config + Runtime on all three days.
• September 25 — Full enforcement.

The Config-only brownouts in weeks one and two are your early warning. If your runners fail to register during those windows, that's your signal to upgrade before the Runtime blocks start and actual jobs stop running.

Note: GitHub Enterprise Server is not affected by this enforcement timeline.

How to audit your runners

If you're on GitHub Enterprise Cloud (standard or Data Residency), you can identify which runner versions are registering through the audit log REST API. Three event types include the runner version in their payload:

• org.register_self_hosted_runner — org-scoped registrations
• repo.register_self_hosted_runner — repo-scoped registrations
• enterprise.register_self_hosted_runner — enterprise-scoped registrations

For large fleets, GitHub recommends querying via the REST API rather than the audit log UI. Filter for events where the runner version is below 2.329.0 to get your list of affected runners.

One caveat: audit log events are recorded at registration time. They show you runners that are actively registering, not a complete inventory of every connected runner. If you have runners that registered months ago and haven't re-registered since, they won't show up in recent logs.

GitHub also plans to surface runtime job annotations when workflows run on outdated runners, so you'll see warnings directly in your workflow logs before enforcement kicks in.

What to do before June 29

The fix itself is straightforward. The operational overhead of keeping it fixed is the real cost.

1. Upgrade all self-hosted runners to the latest supported version. Not just v2.329.0. The latest.
2. Update your provisioning pipeline. Installation scripts, VM images, container images, Terraform modules, Packer templates. Anything that stamps out a runner from a cached base image needs to pull the latest runner binary.
3. Decide on auto-update. If auto-update is enabled, the runner handles the 30-day requirement on its own (as long as it can reach the update service). If you've disabled it for stability or compliance reasons, you need a recurring rebuild or deploy process that keeps pace with releases.
4. Rebuild Docker and ARC runners. Containerized runners with the auto-update flag disabled are the highest-risk category. They won't update themselves, and stale images are easy to overlook.

The auto-update trap

Auto-update sounds like the obvious answer, but it comes with its own tradeoffs for teams that manage runner infrastructure carefully.

Runners with auto-update enabled will pull new versions automatically, which satisfies the 30-day window. But this also means runner versions can change without your knowledge, and a bad runner release could break builds before you've had a chance to test it. Some teams disabled auto-update for exactly this reason.

Those teams now face a choice: re-enable auto-update and accept the risk, or build a manual update pipeline with enough cadence to stay within the 30-day window. Neither is free.

Or skip the maintenance entirely

All of this, the version auditing, the update cadence, the container rebuilds, the brownout monitoring, is operational work that exists solely because you're managing runner infrastructure yourself. With Tenki's managed runners, version patching and compatibility with the new Actions platform architecture are Tenki's responsibility. You change one line in your workflow YAML and your builds run on bare-metal infrastructure that's always current.

Tenki runners are also 30% faster and up to 60% cheaper than GitHub-hosted equivalents, running on ephemeral VMs on Tenki-owned bare metal. So the version enforcement deadline is actually a reasonable moment to reconsider whether maintaining self-hosted runner infrastructure is worth the operational cost when a managed alternative exists.

Brownouts start June 29. If your runners are current, you've got nothing to worry about. If you're not sure, now's the time to check.