Audit GitHub Actions self-hosted runners before the July brownouts

GitHub has confirmed a new enforcement timeline for GitHub Actions self-hosted runners. Confidence level: confirmed. Teams using GitHub Enterprise Cloud with Data Residency face brownouts starting in July and full enforcement on July 31, 2026, while standard GitHub Enterprise Cloud enforcement begins September 25, 2026.

What changed

GitHub Actions is resuming version enforcement for self-hosted runners on github.com and GitHub Enterprise Cloud with Data Residency. Runners must be on version 2.329.0 or later to configure or register, and they must keep up with new runner releases within 30 days to keep executing workflow jobs.

The practical risk is simple: old self-hosted runners can stop registering, stop picking up jobs, or leave workflows queued. GitHub says temporary brownouts will block unsupported runner registration first, then expand to job execution on selected dates before the final enforcement dates.

Key takeaways

• GitHub Enterprise Cloud with Data Residency reaches full enforcement on July 31, 2026.
• Standard GitHub Enterprise Cloud reaches full enforcement on September 25, 2026.
• Version 2.329.0 is the registration floor, not a permanent safe version for job execution.
• Runners with auto-update disabled need a manual update process that tracks every runner release.
• GitHub added runner version visibility to the REST API and recommends audit log checks for registration events.

Availability and access

This affects self-hosted runners connected to github.com, GitHub Enterprise Cloud, and GitHub Enterprise Cloud with Data Residency. GitHub Enterprise Server is not included in the announced enforcement path at this time.

Admins should start with organization and enterprise-level runner lists, then compare runner versions against the changelog dates. If your runner fleet comes from golden images, Kubernetes templates, ephemeral VM images, or cached install scripts, update those sources before replacing only the live machines.

Practical LinkLoot angle

This is a CI reliability issue, not just a housekeeping reminder. Agent-heavy development workflows often depend on self-hosted runners for larger machines, private network access, GPU jobs, mobile builds, or compliance-controlled environments. A brownout can make those workflows look like flaky agents when the real failure is an outdated runner.

Use the window before July 31 to add runner version checks to your CI operations checklist. If you run automation or coding-agent workflows on GitHub Actions, keep a fallback path documented in your AI agent tools workflow so restricted runner capacity does not block releases.

What to verify before you act

• Confirm which GitHub plan and deployment model your organization uses.
• Inventory self-hosted runner versions at repository, organization, and enterprise scope.
• Check whether auto-update is enabled and whether runners can reach the update service.
• Update runner images, container templates, VM snapshots, and install automation.
• Watch the July and September brownout windows before assuming a queued job is an app failure.

Source check

Confirmed by:

• GitHub's changelog names the enforcement dates, the 2.329.0 registration minimum, the 30-day update rule, and the brownout behavior.
• GitHub Docs confirm that self-hosted runners are customer-managed machines and that admins are responsible for the runner environment.

Context:

• GitHub's REST API docs show endpoints for listing and managing self-hosted runners. LinkLoot treats that as implementation context, not as a separate product announcement.