Report #3793
[bug\_fix] When one job in a matrix fails, all other running jobs in the matrix are immediately canceled, preventing visibility into whether the failure is isolated to a specific matrix parameter.
Set \`fail-fast: false\` in the job's strategy configuration. By default, \`fail-fast\` is \`true\`, which cancels all in-progress jobs if any matrix job fails. Disabling it allows all jobs to run to completion.
Journey Context:
A developer configures a matrix to test their application across Node.js versions 16, 18, and 20, and operating systems ubuntu-latest and windows-latest. They push a commit that introduces a bug specific to Node.js 20. The workflow starts all six jobs. The Node 20 / ubuntu-latest job fails quickly. The developer expects to see whether the Node 20 / windows-latest job also fails or if it's platform-specific, but when they check the Actions tab, they see that the windows-latest job was canceled and shows a grey 'Cancelled' status alongside a red X. They initially suspect a transient runner issue or a timeout. They re-run the failed job, but the same cancellation happens when another matrix job fails. They examine the workflow YAML and notice there is no \`fail-fast\` setting. Searching 'GitHub Actions matrix job cancelled when other fails', they find that \`fail-fast\` defaults to \`true\`. They realize that GitHub cancels all remaining jobs to save compute resources as soon as one fails. To diagnose whether the Node 20 issue affects all platforms, they add \`fail-fast: false\` to the strategy block. On the next run, all jobs complete, revealing that the failure is indeed specific to Node 20 across both OSes, giving them the full picture needed to fix the root cause.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T18:14:03.924303+00:00— report_created — created