GitHub Actions concurrency group cancellation order during simultaneous workflow runs

Answer

When you enable concurrency with cancel-in-progress: true, GitHub behaves as follows:

• The currently running workflow instance is cancelled immediately when a new run is queued for the same concurrency group and ref.
• Among the runs that are still queued, GitHub cancels the most recently queued run first, then proceeds to the next‑newest, and so on. The oldest queued run is the last to be cancelled.
• This order is consistent for push, pull_request, and fork events, and it applies per ref (branch or tag). If two workflows target different refs, they are treated as separate concurrency groups.
• There is no configuration flag to change the cancellation priority; the behaviour is hard‑coded by GitHub.

Why this matters for zero‑downtime deployments

Because the running deployment is always the one that gets killed, you should design your deployment workflow to finish quickly or to be idempotent. If a queued run is cancelled before it starts, it simply never runs, so you don’t risk a partial deployment from that instance.

How to verify the order in your own repo

1. Add a concurrency block to your workflow:

   on: push
   concurrency:
     group: "deploy-${{ github.ref }}"
     cancel-in-progress: true
   jobs:
     deploy:
       runs-on: ubuntu-latest
       steps:
         - run: echo "Deploy step"
   

2. Trigger several pushes (or PRs) in quick succession to the same branch. You should see log entries similar to:
   Run 1: started Run 2: cancelled (running) Run 3: cancelled (queued) Run 4: cancelled (queued) Run 5: started
3. Use the API to confirm timestamps:

   curl -H "Authorization: token $TOKEN" \
     https://api.github.com/repos/OWNER/REPO/actions/runs | jq '.workflow_runs[] | {id, run_id, status, started_at, updated_at}'
   

   Check that the run marked as cancelled has the earliest started_at among the running runs, and that queued runs are cancelled in reverse order of created_at.

What if you need more control?

Since GitHub does not expose a priority setting, the typical workaround is to split the deployment into two distinct concurrency groups: one for the “deploy” job and another for any ancillary tasks. Alternatively, you can add a lightweight “queue” job that checks a lock file in a shared storage (e.g., S3 or a database) and only proceeds when it can acquire the lock, thereby serialising deployments at the application level.

Missing diagnostic detail

To tailor the recommendation further, could you let us know whether your workflow triggers are limited to a single branch or span multiple branches/tags? The cancellation scope is per‑ref, so the behaviour can differ if you’re running deployments on several branches concurrently.