GitHub Actions Deploy Canceled Mid-Run by a Concurrency Group

A deployment is aborted partway through because it shares a concurrency group with cancel-in-progress: true. A new push cancels the running deploy, which can leave an environment half-updated.

What this error means

A deploy job is canceled mid-step shortly after another run starts in the same concurrency group, sometimes leaving the target in an inconsistent state.

Canceling since a higher priority waiting request for
'deploy-production' exists

Common causes

Deploy shares a cancel-in-progress group

Reusing a CI-style group with cancel-in-progress: true on a deploy means a newer run cancels the in-flight deployment, which is unsafe for releases.

Group key too coarse for deploys

A group keyed only on the workflow name lets unrelated runs contend, cancelling deploys that should have been allowed to finish.

How to fix it

Let deploys finish - do not cancel them

For deploy jobs, set cancel-in-progress: false so an in-flight deployment completes, and queue the next one.

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

Separate CI and CD concurrency

1. Use a distinct, narrowly scoped concurrency group for deployments.
2. Reserve cancel-in-progress: true for cheap, supersedable CI runs only.
3. Key deploy groups on the target environment so different environments do not block each other.

How to prevent it

• Set cancel-in-progress: false for any deploy or release workflow.
• Keep separate concurrency groups for CI and CD.
• Key deploy concurrency on the environment or ref, not just the workflow.

Related guides