Pimp My IDE / garage dispatch
Back to garage
September 28, 2026 | GitHub Actions / self-hosted runners

Your runner can be online and already late.

GitHub's new enforcement starts September 29. A green status dot does not prove that a self-hosted runner can register tomorrow or execute the next job.

Inventory the installed version. Query both deadlines. Upgrade one canary. Prove one real workflow. Then move the fleet.

The deadline moved to now.

GitHub says full enforcement of its new self-hosted runner minimums begins September 29, 2026 for GitHub Enterprise Cloud. Runners below version 2.329.0 will no longer register or reregister. A separate, higher minimum controls whether an existing runner may execute workflow jobs.[1]

That split matters. Registration and execution are different gates. A runner can remain registered while its ability to take work expires. GitHub Enterprise Server is not part of this change. GitHub Enterprise Cloud with Data Residency began enforcement on July 31.[1]

Do not use "registered" as a synonym for "ready to run the next job."

Do not hard-code the second floor.

GitHub added an organization API that accepts a runner version and returns two fields: registration_deprecates_at and runtime_deprecates_at. The endpoint is GET /orgs/{org}/actions/runners/deprecations/{version}. It requires organization admin access.[2]

The September 28 notice names the registration floor but describes the execution floor only as higher. That is a reason to query the supported endpoint for every installed version. It is not an invitation to guess one fleet-wide number.

Latest is not the same as available.

The public runner repository lists v2.337.0 as its latest release. It was published August 26. The release notes also say the runner follows a progressive release policy, so the newest public release may not yet be offered to every enterprise, organization, or repository.[3]

Use the download instructions shown inside the target GitHub account as the available-version witness. Pin the package digest you actually install. The public release page publishes SHA-256 checksums for each platform package, but this dispatch did not download or execute those packages.

Automatic update still needs an alarm.

GitHub's monitoring guide says the runner application updates itself. The same guide tells operators to check that process because runners below a version threshold cannot process jobs. Update activity appears in Runner_ and SelfUpdate files under the runner's _diag directory.[4]

An auto-updater is a mechanism, not evidence. Alert on its failures. Keep the installed version in inventory. Preserve diagnostic logs outside ephemeral runners. Treat a successful canary workflow as the release check.

Move one runner before moving all of them.

  1. List each runner name, installed version, operating system, architecture, labels, runner group, and current job.
  2. Query the registration and runtime deadline for each distinct installed version.
  3. Drain one representative runner. Save its current package, service configuration, labels, and diagnostic logs.
  4. Install the version offered by the target account. Verify its package digest.
  5. Run a canary workflow that exercises the tools, containers, network routes, and labels that production jobs need.
  6. Roll out in bounded batches. Keep capacity for jobs while each batch drains, upgrades, and returns.
Interactive makeover / runner version pit lane

Put the fleet through the gantry

Traditional purpose replaced: a green runner list and a sticky note with one minimum version. Better version: select the inspection sections, expose the missing handoff fields, and copy a canary plan without pretending that the checks have run.

Select the inspection sections

These controls choose what the handoff will request. They do not inspect a GitHub organization or a runner host.

Canary plan structure
Inspection draft1 of 4 selected
Physical route

Runner inspection gantry

One inspection section is selected.

The handoff still needs three sections. No fleet data or workflow result has been supplied.

What this component proves. It creates a four-section handoff template. It does not authenticate to GitHub, query an organization, read a runner, install a package, or run a canary workflow.

Sources and limits

Open the source log
  1. GitHub Changelog, "Self-hosted runner version enforcement date has moved", published September 28, 2026 and read September 28, 2026. This is the source for the September 29 enforcement date, the v2.329.0 registration floor, the separate higher runtime floor, and the product-scope limits.
  2. GitHub REST API docs, self-hosted runners, read September 28, 2026. The documented endpoint returns registration and runtime deprecation dates for one runner version and requires organization admin access.
  3. GitHub Actions runner v2.337.0 release and release API record, published August 26, 2026 and read September 28, 2026. These verify the latest public release tag, package records, checksums, and progressive-rollout note. We did not install the release.
  4. GitHub Docs, "Monitoring and troubleshooting self-hosted runners", read September 28, 2026. This is the source for status meanings, connectivity checks, diagnostic-log locations, and automatic-update monitoring.

Evidence boundary. This dispatch read public GitHub documentation and release metadata. It did not authenticate to an organization, inspect a fleet, query a private deprecation schedule, install a runner, or execute a workflow. The checklist is an operating recommendation.