GitHub plans macOS 14 runner brownout for 5 October
Updated 31 October 2026: GitHub still plans to retire its hosted macOS 14 runner images on 2 November 2026. The affected workflow labels are macos-14, macos-14-large and macos-14-xlarge. Its current retirement issue also lists two further planned brownouts before that deadline. Teams should finish testing a compatible replacement rather than assume the end of October’s earlier warnings means the old image will remain available.
The original report covered GitHub’s planned interruption from 5 October at 14:00 UTC to 6 October at 00:00 UTC. The 1 October changelog lists eight windows, starting on 5, 12, 16, 19, 23, 26, 29 and 30 October. Each runs from 14:00 UTC until 00:00 UTC the following day. Those eight listed periods have now ended.
The linked retirement issue currently includes two additional periods: 31 October at 14:00 UTC to 1 November at 00:00 UTC, and 1 November at 14:00 UTC to 2 November at 00:00 UTC. These later entries are absent from the eight-window changelog list. They remain published warnings to plan around, not evidence that any particular job has already failed. Both sources retain the 2 November retirement date.
During a brownout, jobs using the retiring images are intended to terminate with an error. GitHub also warns that capacity may decline before withdrawal, potentially increasing queue times. The notice does not provide a measured outage count, a migration-completion rate or a guarantee about an individual workflow.
Match the replacement to the job
GitHub’s changelog names arm64 alternatives: macos-latest (macos-26), macos-15, macos-latest-xlarge (macos-26-xlarge) and macos-15-xlarge. The retirement issue separately directs macos-14-large users towards macos-latest-large or macos-15-large.
The current runner-images repository identifies the retiring macos-14-large image as x64, while macos-14 and macos-14-xlarge are arm64. Changing to an arm64 label is therefore an architecture change for a job that relied on the x64 image. Check the intended replacement’s architecture, availability and installed software. A label change alone does not establish compatibility, and a -latest alias can move to a newer operating-system image.
Inventory every workflow and reusable workflow using the old labels. Run representative builds on the intended replacement, then review architecture-sensitive dependencies, signing, packaging and deployment separately. Keep evidence of the results and a usable fallback that does not depend on an image scheduled for removal. Record which repositories have moved, who owns each exception and what still needs testing. These checks do not claim that one replacement suits every workflow or that a migration is complete.
The BlackTree Lifecycle record tracks this scheduled, changeable hosted-image retirement. It is not an Apple macOS 14 operating-system support deadline or a measurement of brownout failures. For pipelines that include security analysis, BlackTree’s CodeQL scan-continuity report explains why a successful configuration change also needs evidence that the intended analysis actually completed.
