GitHub Actions concurrency in a reusable workflow cancels the wrong run in CI

A concurrency group defined inside a reusable workflow is shared across every caller that uses it. If the group key is static, one caller's run cancels another's. Scope the key with caller context so groups stay independent.

What this error means

Runs from different branches or callers cancel each other unexpectedly, because the reusable workflow uses a fixed concurrency group name shared by all invocations.

Canceling since a higher priority waiting request for
'deploy-group' exists
# a static concurrency group inside deploy.yml is shared by all callers

Common causes

A static concurrency group in the callee

The reusable workflow sets concurrency: deploy-group with no per-caller context, so all callers land in one group and cancel each other.

No caller context in the group key

Without github.ref, github.workflow, or an input in the key, distinct runs are treated as the same concurrency group.

How to fix it

Scope the concurrency group with context

1. Include a caller-specific value (github.ref, an input) in the group key.
2. Keep the group unique per environment or branch.
3. Re-run so independent callers no longer cancel each other.

# deploy.yml
concurrency:
  group: deploy-${{ inputs.environment }}-${{ github.ref }}
  cancel-in-progress: true

Set concurrency in the caller instead

If the group should be per-caller, define concurrency in the calling workflow where the full caller context is available.

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

How to prevent it

• Include caller context in any concurrency group used by shared workflows.
• Decide deliberately whether concurrency belongs in the caller or callee.
• Test with two branches to confirm groups do not collide.

Related guides