GitHub Actions job cancelled by concurrency policy

What this failure means

A GitHub Actions workflow run was automatically cancelled because a newer run for the same concurrency group started. All pending and in-progress steps were cut short. No action or fix is needed — this is expected behaviour from a concurrency: cancel-in-progress: true policy.

Symptoms

Faultline looks for one or more of these log fragments:

The operation was canceled
the operation was cancelled
This run was cancelled
Cancelling a currently running workflow
Job was canceled
##[error]A task was canceled

Diagnosis

GitHub Actions supports a concurrency block at the workflow or job level. When cancel-in-progress: true is set, any in-progress run for the same group is cancelled as soon as a newer run begins for that group (e.g., a new push to the same branch):

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

When cancellation fires:

• The runner receives a cancel signal.
• Any currently running step receives SIGTERM; pending steps are skipped.
• The log shows: The operation was canceled. or Cancelling a currently running workflow followed by all remaining steps marked as cancelled or skipped.

This is not a failure — it is the concurrency policy working as designed. If the cancellation is unexpected, check whether the branch or event grouping expression is too broad.

Fix steps

If the cancellation is expected (new push after old push): No action needed. The newer run will complete.

If the cancellation is too aggressive (unrelated runs cancelling each other):

1. Narrow the concurrency group expression to avoid false matches:

   # Too broad — all pulls cancel each other regardless of branch:
   concurrency:
     group: ${{ github.workflow }}
     cancel-in-progress: true
   
   # Better — only runs on the same branch cancel each other:
   concurrency:
     group: ${{ github.workflow }}-${{ github.ref }}
     cancel-in-progress: true
   

2. Protect critical post-merge jobs from cancellation by setting cancel-in-progress: false on the deploy or release workflow:

   concurrency:
     group: deploy-${{ github.ref }}
     cancel-in-progress: false  # Never cancel an in-progress deploy
   

3. Use separate concurrency groups for PR checks (cancel-in-progress: true) and post-merge deployment (cancel-in-progress: false).

If the concurrency block is not intentional:

Remove or adjust the concurrency: block from the workflow YAML.

Validation

• Push a new commit and confirm only the newer run executes.
• Confirm no unrelated runs are cancelled under the new configuration.

Why it matters

Concurrency cancellation is a normal and desirable behaviour for CI checks on active branches — there is no value in completing a check on a commit that has already been superseded. However, it becomes a problem when:

• The concurrency group is too broad and cancels genuinely independent jobs.
• A post-merge deployment run is cancelled by a concurrent hotfix push.
• A developer misreads the cancellation as a flaky failure.

Understanding that The operation was canceled. originates from a concurrency policy — not from a test failure, timeout, or runner issue — prevents unnecessary investigation.

Prevention

• Always set per-branch concurrency groups rather than per-workflow groups.
• Mark deploy and release workflows with cancel-in-progress: false.
• Add a comment in the workflow YAML explaining the concurrency strategy.

Try it locally

grep -r "cancel-in-progress" .github/workflows/
grep -r "concurrency:" .github/workflows/
grep -r "concurrency:" .github/workflows/ | head -20

How Faultline detects it

Use faultline explain github-actions-concurrency-cancel to see the full playbook.

faultline analyze build.log
faultline explain github-actions-concurrency-cancel

Generated from playbooks/bundled/log/ci/github-actions-concurrency-cancel.yaml. Do not edit directly.