GitHub Actions if: always() still skipped when dependency is canceled
always() forces a step to run regardless of prior success or failure, but a canceled run can still stop dependent jobs. Understanding always() vs !cancelled() prevents surprising skips.
What this error means
A cleanup step with if: always() does not run after the workflow is canceled, or a dependent job is skipped on cancellation despite always().
# Cleanup did not run because the job was canceled upstream
- if: always()
run: ./cleanup.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
Cancellation propagates as a skip
A canceled dependency can skip downstream jobs even with always() at step scope.
Confusing always() with !cancelled()
always() runs on failure but you may actually want to honor cancellation differently.
How to fix it
Choose the correct status function
- Use if: always() to run on success, failure, and cancellation at the step level.
- Use if: \${{ !cancelled() }} to run unless canceled.
- For dependent jobs, combine status functions with needs.<job>.result checks.
- name: Always upload logs
if: always()
uses: actions/upload-artifact@v4
with:
name: logs
path: ./logsCatch 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
- Pick always() vs !cancelled() vs success()/failure() deliberately.
- Test cancellation paths, not just success, for cleanup steps.