GitHub Actions macOS 14 Retirement: What Breaks on October 5

If any of your GitHub Actions workflows run on macos-14, they will start failing intermittently on October 5, 2026. GitHub has announced eight brownout windows between now and the final retirement on November 2, 2026, and in each one, jobs on the macOS 14 image will fail rather than queue. There is a second problem hiding in the same announcement that will bite people who think they are already migrated.

The retirement is straightforward to handle: move off macos-14, macos-14-large and macos-14-xlarge onto macos-15 or macos-latest. The trap is that macos-latest now resolves to macos-26, not macOS 15. If your workflow pinned macos-latest expecting a 15-series runner, you are already on a different major OS than you think, and switching off macos-14 by moving to macos-latest is a second, larger change than it looks.

Key takeaways:

First brownout: October 5, 14:00 UTC. Jobs on macOS 14 fail outright, they do not queue.
Hard retirement: November 2, 2026.
macos-latest now means macos-26. That is a major OS jump, not a point release.
Queue times may already be degrading. GitHub warns it may reduce macOS 14 capacity during the lead-up.
Pin an explicit version if you can. macos-latest is a moving target and this announcement is proof.

Table of Contents

The eight brownout windows

GitHub’s terminology is important here. A brownout is not a slow queue. During these windows, jobs using the macOS 14 runner image temporarily fail.

#	Window opens (UTC)	Window closes (UTC)
1	Oct 5, 14:00	Oct 6, 00:00
2	Oct 12, 14:00	Oct 13, 00:00
3	Oct 16, 14:00	Oct 17, 00:00
4	Oct 19, 14:00	Oct 20, 00:00
5	Oct 23, 14:00	Oct 24, 00:00
6	Oct 26, 14:00	Oct 27, 00:00
7	Oct 29, 14:00	Oct 30, 00:00
8	Oct 30, 14:00	Oct 31, 00:00

Source: GitHub Changelog, 1 October 2026. Full retirement follows on November 2, 2026.

Note that windows 7 and 8 are back to back, and that the whole schedule ends the day before the hard retirement. The brownouts are a grace period, not a soft landing — they exist so you find the problem before November 2 forces it.

The label that has quietly moved under you

This is the part worth reading twice. GitHub lists the migration targets as:

macos-latest — which is now macos-26
macos-15
macos-latest-xlarge — which is now macos-26-xlarge
macos-15-xlarge

So macos-latest is no longer “the newest macOS GitHub has a stable image for, which was 15.” It points at macOS 26. If a workflow was written years ago with runs-on: macos-latest, it has been silently moving under you the whole time, and it is currently on a different major version than the one before it.

That has two consequences. First, migrating from macos-14 to macos-latest is a one-line change that jumps you across two major OS versions, which is a much bigger test surface than it looks. Second, any workflow that was implicitly stable because macos-latest was not moving is no longer stable. This is the general argument for pinning explicit labels, and this announcement is the demonstration.

Finding affected workflows

Start by searching your own organisation or account for the retired labels:

# Across an organisation
gh search code "macos-14" --owner your-org --json repository,path,textMatches

# Locally, across every workflow in a repository
grep -rn "macos-14" .github/workflows/

Then check whether anything self-hosted is affected. The announcement covers GitHub-hosted images, but it is worth knowing what you actually have:

gh api /repos/your-org/your-repo/actions/runners 
  --jq '.runners[] | {name: .name, os: .os, status: .status, labels: .labels[].name}'

What to do, in order

Today: grep for macos-14, macos-14-large and macos-14-xlarge. That is the whole affected set.
Today: audit every macos-latest usage in the same pass, because it now resolves to macos-26.
Before October 5: move to macos-15 if you want the smallest possible change, or to macos-26 deliberately if you want current.
On a branch: run the migrated workflow once and read the log. Xcode toolchain changes are the usual breakage on a major OS jump.
Consider pinning macos-15 or macos-26 explicitly instead of macos-latest, so the next image change is your decision rather than GitHub’s.
Watch your queue times now. GitHub warns it may reduce macOS 14 runner capacity before the date, so slow builds can precede the first brownout.

Why GitHub does this at all

Runner images are not free. Each macOS image is a hosted VM, and the image is rebuilt regularly as the OS updates. Retiring a version is how the capacity gets reclaimed and the image set stays maintainable. The brownout schedule exists because a large share of GitHub-hosted Actions usage never pins a version, so an abrupt retirement would break workflows nobody knew were affected.

That reasoning is sound. The uncomfortable part is that the same design decision — a floating macos-latest label — is what makes the migration harder than the retirement itself. If every workflow had been pinned to macos-14, this would be a find-and-replace. Because many were on macos-latest, half the work is discovering that a label you thought was stable had already jumped a major version.

Worth checking your own pipeline for the same pattern. The same argument applies to self-hosted runner images, container base images referenced by floating tags, and action versions pinned to a branch rather than a commit SHA.