GitHub Actions continue-on-error on a matrix hides a real failing leg
continue-on-error lets a step or job fail without failing the run. Applied to a whole matrix it masks every failing leg, so a broken combination passes CI silently and required checks go green.
What this error means
A matrix leg clearly failed in its logs, yet the job and the overall run are reported as successful.
strategy:
matrix:
target: [a, b, c]
continue-on-error: true # every leg can fail without failing the run
# target=b failed but the run is greenDiagnose it: print the context before you change anything
Most workflow-expression bugs are not syntax errors, they are an expression reading something that is empty. GitHub resolves a missing property to an empty string instead of failing the run, so a wrong reference looks like a logic bug rather than a mistake. Dump the contexts first and you will usually see the answer immediately.
- name: Dump contexts
run: |
echo '--- github ---' ; echo '${{ toJSON(github) }}'
echo '--- needs ---' ; echo '${{ toJSON(needs) }}'
echo '--- steps ---' ; echo '${{ toJSON(steps) }}'
echo '--- matrix ---' ; echo '${{ toJSON(matrix) }}'
echo '--- inputs ---' ; echo '${{ toJSON(inputs) }}'Check the context is allowed where you used it
Contexts are not available everywhere. The same expression can be valid in a step if and invalid in a job if, which is why an expression that works in one workflow fails when moved.
| Where you wrote it | Contexts available there |
|---|---|
run-name | github, inputs, vars |
concurrency | github, inputs, vars |
Top-level env | github, secrets, inputs, vars |
jobs.<id>.if | github, needs, vars, inputs |
jobs.<id>.steps.if | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs |
jobs.<id>.outputs | Full access, including secrets |
Reusable workflow outputs | github, jobs, vars, inputs |
Common causes
continue-on-error applied at job level over the matrix
It suppresses the failing status of every matrix leg, not just a known-flaky one.
Intent was to tolerate one leg, not all
Tolerating a single experimental combination requires scoping continue-on-error to that include entry.
How to fix it
Scope continue-on-error to a single include leg
- Move continue-on-error into the specific matrix combination you want to tolerate via include.
- Leave the rest of the matrix strict so real failures fail the run.
strategy:
matrix:
target: [a, b]
include:
- target: experimental
experimental: true
steps:
- run: ./build.sh ${{ matrix.target }}
continue-on-error: ${{ matrix.experimental == true }}Remove blanket continue-on-error
- Delete job-level continue-on-error unless every leg is genuinely allowed to fail.
- Use fail-fast: false to keep legs independent without hiding failures.
Catch it before it reaches CI
Every failure in this cluster is statically detectable. actionlint parses workflow expressions, checks context availability against the same rules above, and validates needs references, so these bugs never need to cost you a run.
# one-off
docker run --rm -v "$(pwd):/repo" --workdir /repo rhysd/actionlint:latest -color
# as a job, before anything expensive runs
- uses: actions/checkout@v4
- run: |
bash <(curl -s https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
./actionlint -colorHow to prevent it
- Keep continue-on-error as narrow as possible.
- Audit required checks to ensure they actually go red on real failures.