Report #9313
[bug\_fix] Matrix strategy cancels all in-progress jobs when a single job fails
Set \`strategy: fail-fast: false\`. Root cause: The default \`fail-fast: true\` immediately aborts the entire matrix on first failure to conserve runner minutes.
Journey Context:
A development team maintains a cross-platform application requiring testing on Ubuntu, Windows, and macOS across Node.js versions 16, 18, and 20. They configure a matrix strategy with \`os: \[ubuntu-latest, windows-latest, macos-latest\]\` and \`node-version: \[16, 18, 20\]\`, creating 12 parallel jobs. They push a commit introducing a platform-specific bug affecting only Windows. The workflow starts, and within two minutes, the Windows \+ Node 16 job fails with a test error. Instantly, the UI shows all other 11 jobs \(including Ubuntu and macOS runs that were passing\) as "cancelled" with a grey X. The developer cannot see whether the bug affects only Windows or all platforms, and doesn't know if Node 18/20 on Windows are also broken. They must manually re-run the cancelled jobs or push a fix and wait for a full matrix run again. After several painful iterations of this pattern, they examine the workflow documentation and discover the \`fail-fast\` strategy option. They learn that GitHub defaults this to \`true\` to save compute costs by aborting the matrix as soon as any job fails. For their use case of platform compatibility testing, this behavior is counterproductive because they need the full matrix results to understand the blast radius of a bug. By adding \`strategy: fail-fast: false\` to their job definition, the matrix continues running all combinations regardless of individual failures, providing a complete report of which specific OS/Node combinations pass or fail in a single CI run.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T07:48:54.928128+00:00— report_created — created