GitHub Actions retires the macOS 14 runner image on November 2 and fails unmigrated jobs during October brownouts
GitHub will retire the macOS 14 runner image on November 2, 2026 and is already failing jobs that still use it during eight brownout windows spread across October. Migrate your workflows to an arm64 label — macos-15 or macos-latest — before the next outage on October 12.
October 1, 2026. GitHub announces it will retire the macOS 14 runner image on November 2, 2026. From October 5 to 6, the first brownout already failed jobs still pinned to that label. Eight windows of deliberate outages are scheduled before the end of the month. For any team whose macOS CI is critical — app builds, code signing, Xcode tests — the consequence is immediate: a workflow that still references macos-14 will break during these windows, then permanently from November 2.
What GitHub is actually retiring
The retirement covers three hosted labels: macos-14, macos-14-large, and macos-14-xlarge. In effect, the entire macOS 14 Sonoma image family disappears from GitHub’s hosted runner fleet. A job that declares runs-on: macos-14 will soon have no machine to run on at all.
To force the migration rather than let teams discover the failure on the day, GitHub is reusing its usual brownout mechanism: jobs targeting macos-14 deliberately fail during scheduled windows, as an early warning. Eight windows stretch across October, each from 14:00 UTC to midnight UTC the following day:
- October 5–6 (already passed);
- October 12–13;
- October 16–17;
- October 19–20;
- October 23–24;
- October 26–27;
- October 29–30;
- October 30–31.
On top of that there is a quieter pressure: during the transition, GitHub may reduce macOS 14 runner capacity, which can produce longer queue times for jobs that still use those labels. The result is a silent failure — no explicit error message — that teams easily mistake for plain slowness.
Why now: the Apple Silicon shift
This retirement is not an isolated event; it is the next step in an arm64 transition that has been underway for months. GitHub made macOS 26 (Tahoe) generally available on February 26, 2026, with runners executing natively on Apple Silicon (arm64) while keeping an Intel (x64) image available. The recommended migration points at arm64 labels: macos-latest (now pointing to macOS 26), macos-15, and their -xlarge variants.
The key consideration for teams still on Intel is a single label: macos-15-intel. This is the last x86_64 image that GitHub Actions will offer, available until August 2027. A team that cannot yet build or sign on arm64 is not left without options — but it must say so explicitly, because the platform’s default is now arm64.
That is where the trap lies. Many workflows were written back when macos-latest still pointed to an Intel image. Migrating “blindly” from macos-14 to macos-latest changes the architecture too, not just the OS version. An x86_64 dependency — a precompiled tool, an extension, a home-grown binary — can then break in subtle ways, at build time rather than at declaration time.
What breaks if you do nothing
The degradation unfolds in three stages. During the brownouts, macos-14 jobs simply fail: a mobile build or signing pipeline halts and releases are blocked. Between brownouts, reduced capacity lengthens queues and slows the whole pipeline without an explicit alert. After November 2, the image no longer exists: the failure becomes permanent.
For a mobile team, the stakes go beyond inconvenience. iOS and macOS builds almost always run on a macOS machine to compile with Xcode, run simulator tests, then sign artifacts. A retired label means an entire delivery chain stops — and a hotfix can no longer ship until the workflow is migrated. The time to fix it is not the retirement date; it is now.
Migrating in practice
The first step is an inventory, not a fix. Before touching anything, list the workflows still pinned to the condemned labels:
# List workflows that still reference the retired labels
grep -rn "macos-14" .github/workflows/The fix itself is a single line of YAML. The target GitHub recommends is an arm64 label:
# .github/workflows/ci.yml — before
jobs:
build:
runs-on: macos-14
# .github/workflows/ci.yml — after
jobs:
build:
runs-on: macos-15 # or macos-latest (macOS 26, arm64)Two hygiene rules go with this switch. First, do not move to macos-latest without checking the architecture: if your chain still ships an Intel binary, prefer macos-15-intel while you recompile, and schedule the arm64 migration before August 2027. Second, pin your versions instead of following macos-latest: the retirement of macos-14 is exactly the kind of event that punishes unpinned workflows, just as the ubuntu-latest migration to Ubuntu 26.04 did last month.
For teams on self-hosted runners, the retirement does not apply directly — you provide your own machines. But the software image you install on them remains your responsibility: if you froze a macOS 14 Sonoma environment, the question of updating it arises in the same way, just on your own schedule.
The arm64 migration traps
Moving from macos-14 to macos-latest changes the architecture, and that switch has concrete effects most teams discover at the first broken build. The most common is Homebrew: on Intel runners packages install under /usr/local, whereas on Apple Silicon the prefix becomes /opt/homebrew. Any script that hard-codes a path — a PATH, a bundle install, a pinned brew --prefix — fails with no obvious message.
The second trap is precompiled binaries. An x86_64 dependency checked into the repo, a signing tool, or a proprietary SDK does not run natively on arm64. Rosetta 2 can run x86_64 on Apple Silicon, but leaning on it for a production pipeline masks the problem instead of solving it: the emulated binary works, until the day it becomes the bottleneck or the point of failure in a release.
Two commands are enough to take stock before cutting over:
# Architecture of the runner's machine
uname -m
# Architecture of a suspicious binary
file ./my-toolThe recommended approach fits in one line: cut over with a canary job first. Duplicate the critical workflow on macos-15 alongside macos-14, compare the artifacts, then drop the old label once the canary has been green across several runs. That is the only way to turn an architecture migration into routine work instead of a gamble.
The -large and -xlarge labels deserve a word of their own. Heavy Xcode builds — compiling a large Swift codebase or running a full simulator matrix — often outgrow the standard two-vCPU runner. GitHub’s macos-14-large and macos-14-xlarge supplied that headroom, and their arm64 successors are macos-latest-xlarge (pointing at macos-26-xlarge) and macos-15-xlarge. If your workflow depends on the bigger machines, renaming the label is not the whole job: verify the replacement label exists, carries the vCPU count you need, and that its per-minute multiplier still fits your budget — xlarge runners bill at a premium. The authoritative list of what each image includes lives in the runner-images repository, and checking it before a brownout is cheaper than discovering a missing toolchain mid-release.
Verdict
If your workflows still use macos-14, treat the next brownout on October 12 as a hard deadline: run the grep inventory today, migrate to macos-15 or macos-latest, and confirm the build passes on arm64. If your chain depends on Intel binaries, switch to macos-15-intel immediately, but put the arm64 recompile on the backlog — that label disappears in August 2027. If you manage a fleet of repositories, automate the detection: a weekly check that scans .github/workflows/ for deprecated labels beats eight brownouts endured blindly. The underlying lesson is the same as with ubuntu-latest: on GitHub Actions, a runner’s default version is a dated liability, not a guarantee of stability.