GitHub Actions Node24 Error on Self-Hosted Runners: Upgrade the Runner First

Identify which Node24 boundary failed#

The error wording usually tells you which layer to inspect first:

Do not treat every Node24 failure as a YAML syntax error. The action and the runner are two versioned components, and they can be upgraded independently.

Check the action and runner versions#

Some current JavaScript actions have already moved to Node24. For example, the actions/checkout README documents Node24 for checkout@v5 and requires runner v2.327.1 or newer. The actions/cache README documents the same runner floor for cache@v5.

That minimum is an action-runtime requirement. It is not the same as GitHub’s separate runner registration enforcement.

If you can query the repository’s self-hosted runners, inspect their reported versions without exposing runner credentials:

1
gh api --paginate repos/OWNER/REPO/actions/runners \
2
  --jq '.runners[] | [.name, .version, .os, .status, .busy] | @tsv'

The REST response is repository-scoped, so use the organization or enterprise endpoint when that is where the runner is registered. The self-hosted runner API requires the permissions appropriate to the endpoint; a failed query does not prove that the runner is outdated.

Also inspect the action versions in the failing job:

1
steps:
2
  - uses: actions/checkout@v5
3
  - uses: actions/cache@v5

Read the action’s release notes before assuming that a tag change is safe. A temporary pin to an older action can unblock an incident, but it leaves the runner upgrade undone and should not become the permanent fix.

Upgrade the self-hosted runner#

Use the runner package and service instructions from the repository, organization, or enterprise runner settings. A safe upgrade sequence is:

1. Stop new jobs from selecting the runner, or take it offline through the runner settings.
2. Record the installed runner version, operating system, architecture, labels, and service definition.
3. Install the current runner package for that host and reconnect it using the supported setup flow.
4. Keep the same labels and working-directory policy, then run a small workflow that uses the failing action.
5. Return the runner to service only after the action completes and the runner reports the expected version.

Self-hosted runners update automatically by default. If you disabled that behavior, GitHub’s self-hosted runner documentation says to update the runner regularly and within 30 days. A runner that cannot reach the update service can become a queueing or enforcement problem even after you fix the immediate Node24 error.

Separate runtime support from registration enforcement#

GitHub’s minimum-version enforcement timeline describes a second floor: runner v2.329.0 or newer is required to register or re-register in the affected GitHub-hosted product cohorts. Job execution also requires runners to stay within the update window. That policy is separate from the v2.327.1 runtime floor documented by particular Node24 actions.

For GitHub Enterprise Cloud, the same timeline announces brownouts beginning August 24, 2026 and full enforcement on September 25, 2026. If your self-hosted fleet serves that product, treat those dates as an upgrade deadline rather than waiting for a workflow to fail. GitHub Enterprise Server is not covered by that timeline, but its runner compatibility still depends on the GHES release and runner version you operate.

Check the host operating system#

If the runner binary is new enough but the action still cannot start Node24, check the host platform. GitHub’s Node runtime migration notice calls out macOS 13.4 and lower as incompatible with Node24, and it notes that official ARM32 support ends with the Node20 deprecation path.

That makes these labels worth checking before changing the workflow:

1
os=macos, version=13.4 or lower
2
architecture=arm32

Move the job to a supported host, or provision a new self-hosted runner with an architecture and operating system that the action runtime supports. Do not hide the incompatibility by adding a broad fallback to every job.

Use the old-runtime fallback only as a bridge#

GitHub’s migration notice documents ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true as a temporary way to allow an older JavaScript action runtime during migration. If you must use it to recover a release, scope it to the affected runner or job, record the expiry, and remove it after the runner is upgraded.

The fallback reduces the urgency signal; it does not add Node24 support, fix a registration policy failure, or make an unsupported operating system safe. Keep the normal workflow on the new runtime path once the runner fleet is ready.

Verify the fix at the same boundary#

Run the failing workflow on the upgraded runner and confirm all of these facts:

1. The runner API reports the new version and the expected labels.
2. The job is actually scheduled on that runner, not on another old machine with the same label.
3. The Node24 action starts without the using: node24 error.
4. The runner service can receive its next automatic update.
5. The host OS and architecture match the action’s support notes.

If the job then fails because a secret is empty, that is a different workflow boundary. GitHub Actions reusable workflow secrets covers the caller-to-called-workflow handoff; do not mix that diagnosis with a runner-runtime upgrade.

FAQ#