GitHub Actions concurrency group cancellation order during simultaneous workflow runs
0 reputation · 01 Dec 2025, 02:46 UTC
Goal
Maintain zero‑downtime migration for a small application by using a single concurrency group to prevent overlapping deployments.
Uncertainty
The GitHub Actions documentation states that a new run will cancel the currently running run within the same concurrency group, but it does not specify which run is cancelled when multiple runs are queued. Users report conflicting behaviors: some see the oldest running run cancelled, others observe the newest queued run being terminated first. This ambiguity can leave the application in an inconsistent state if the wrong run is cancelled mid‑deployment.
Questions
1. When several runs are queued in a concurrency group, which run does GitHub cancel first— the oldest running run or the newest queued run?
2. Is the cancellation order consistent across different event types (push, pull request, fork) and repository contexts?
3. Does GitHub provide any deterministic rule or configuration to control the cancellation priority within a concurrency group?
github