GitHub Actions success() and failure() both false when the run is cancelled
success() is true only when prior steps succeeded; failure() is true only when one failed. A cancelled run is neither, so a step guarded by success() || failure() is skipped - cleanup that should always run does not.
What this error means
A cleanup or teardown step is skipped when a job is cancelled, even though it should run regardless of outcome.
- name: Teardown
if: ${{ success() || failure() }} # both false on cancel -> step skipped
run: ./teardown.shDiagnose 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
cancelled() is a distinct state
A cancel is neither success nor failure; cancelled() must be checked separately or always() used.
Misuse of success() || failure() as a catch-all
That combination excludes cancellation; it is not equivalent to always().
How to fix it
Use always() for unconditional cleanup
- Replace the success/failure combination with always() so the step runs in every outcome including cancellation.
- Inside the step, branch on the specific status if needed.
- name: Teardown
if: ${{ always() }}
run: ./teardown.shExplicitly include cancelled()
- If you do not want always(), add || cancelled() to cover the cancel state.
- Combine the three status functions for the exact set you intend.
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
- Use always() for teardown that must run on cancellation.
- Remember cancelled() is separate from success() and failure().