GitHub Actions macos-14 Jobs Failing? Retirement Dates and Migration Choices

An unchanged workflow can still hit a planned failure

GitHub's macOS 14 retirement notice schedules deliberate job failures before the image disappears on November 2. First compare your failing job's label and timestamp with the notice. Failures on other images or outside these windows need their own diagnosis.

The affected labels are macos-14, macos-14-large and macos-14-xlarge. Remaining windows as of October 26 are:

Reduced capacity can also lengthen queues before retirement. Retrying after a brownout is not a migration plan for November 2.

Keep the architecture decision explicit

The current image catalog maps macos-latest to macOS 26 on arm64. The old standard and xlarge macOS 14 labels are arm64; the large label is Intel.

Standard Intel options also exist as macos-15-intel and macos-26-intel. Moving from a large runner to a standard one changes machine specifications as well. Select the machine your job needs before deciding which label to substitute.

Follow variables and reusable workflows

Runner selection uses runs-on, which can contain a literal label or a variable. Start by locating references:

rg -n 'macos-14' .github

Inspect matrix entries and any reusable workflow that selects the machine. For an arm64 macOS 15 job, the direct setting is runs-on: macos-15. A clean local search does not inspect the contents of an externally referenced workflow.

Verify the toolchain that actually runs

As checked on October 26, the macOS 15 arm64 inventory lists Xcode 16.4 as its default; the macOS 26 arm64 inventory lists Xcode 26.6. Review scripts that select a fixed application path.

A diagnostic step can record the environment before the build:

uname -m
sw_vers
xcodebuild -version

Then rerun dependency installation, compilation and tests, and validate the deliverable. Successful scheduling proves that the new runner was found; the build and artifact checks establish whether the migration works for your project.