GitHub Actions macOS 14 Brownouts Start October 5: Why Jobs Will Fail and How to Migrate

Is GitHub Actions macOS 14 already retired?

No, as of October 2, 2026. GitHub opened its retirement notice on January 11. Deprecation began July 6, when GitHub warned that peak usage could cause longer queues. Scheduled brownouts begin October 5, followed by full retirement on November 2. The retirement plan was first announced in January 2026. GitHub reiterated the timeline in an October 1 Changelog as the first brownout approaches.

The notice covers GitHub-hosted runner images. A workflow running on a self-hosted Mac requires a separate assessment; its operating system name alone does not establish that this hosted-image schedule applies.

Complete macOS 14 brownout schedule

GitHub says builds scheduled on the affected images during these windows will fail. All dates below are in 2026, and all times are UTC. The end falls on the following calendar day. Official schedule

What happens during a brownout?

A brownout is a scheduled interruption intended to surface remaining use of the retiring images. The notice names macos-14, macos-14-large and macos-14-xlarge. It does not establish a stable exact error string to match, and we have not reproduced a brownout failure before the first window.

Our diagnostic recommendation: record the failed run’s UTC timestamp, resolved runner label and logs, then compare them with the schedule. Check reusable workflows, matrix values and variables when the label is not written directly in the failing job. A failure outside these windows, or on another image, needs its own investigation. The schedule does not mean every macOS 14 job fails continuously from October 5 onward.

What should I replace each label with?

The replacement list below follows the retirement notice; architecture comes from the current runner-images table and larger runner reference. Preserve architecture deliberately when choosing your test target.

For an Intel workflow using macos-14-large, standard macos-15 is an architecture change to arm64. Test macos-15-large if you want to preserve Intel while moving one OS generation. The current runner-images table maps macos-latest-large to macOS 26 x64, so that choice preserves architecture but makes a larger OS jump.

For macos-14-xlarge, test the supported xlarge variant that matches the required software baseline. A standard arm64 label has the same CPU architecture, but it does not imply the same runner size or capacity.

Why macos-latest may be a bigger migration than expected

As verified October 2, macos-latest points to macOS 26 arm64. GitHub’s May migration announcement scheduled the move from macOS 15 to macOS 26 to begin June 15 over 30 days. The current image table confirms the resulting mapping.

Our recommendation for controlled change is to test an explicit supported label first. macos-15 fixes the selected major OS version; it does not freeze the image’s patch level or preinstalled toolchain. GitHub updates image software over time. A latest alias also allows a future major OS migration.

Should I choose macOS 15 or macOS 26?

There is no universal winner. Start with required Xcode versions, SDKs, simulator runtimes, native dependencies and CPU architecture. A smaller OS jump can reduce the changes you investigate at once, but a required newer SDK or toolchain may favor macOS 26.

Compare the current inventories for macOS 14 arm64, macOS 15 arm64 and macOS 26 arm64, or their 14 Intel, 15 Intel and 26 Intel counterparts. Default and available Xcode versions differ, as do compiler and runtime baselines. Check your selected Xcode path and installed runtime rather than assuming an old path remains available.

These inventories change frequently. A successful label substitution is only the start of validation; it does not establish that the resulting binary, tests or release artifacts are correct.

Migration checklist before October 5

Our recommended sequence:

1. Find affected labels in .github/workflows, reusable workflows and matrix or variable definitions. A repository search for macos-14 is a useful starting point.
2. Record whether each job needs arm64 or Intel/x64, plus required Xcode, SDKs, simulator runtimes and language tools.
3. Choose a supported label from the table and compare its current software inventory.
4. Change a branch and run the real build and test matrix. Verify the resolved image and architecture in the run logs.
5. Inspect generated artifacts and, where applicable, signing, packaging and native dependency behavior.
6. Merge the validated replacement before October 5 at 14:00 UTC. Confirm subsequent scheduled and release workflows also use it.

What happens after November 2?

GitHub says macOS 14 images become fully unsupported on November 2, 2026, and workflows using them will be terminated with an error. Switching back to an affected macOS 14 label is therefore not a durable rollback plan. Keep a validated supported image available for recovery. Recheck the official notice before relying on any future date; GitHub can revise the schedule.