GitHub Actions deployment queues: decide what may be replaced

First decide whether the waiting request is disposable

A new commit can make an older pending CI check unnecessary. A new release request does not necessarily make an earlier approved release unnecessary. Before giving an agent deployment authority, decide which of those situations applies. GitHub Actions concurrency controls which participating jobs or runs may run and wait together; its default pending slot is not a retain-every-release queue.[1][2]

• Name the target and every writer that can change it, including release workflows, manual paths and other repositories.
• Define supersession explicitly: may a newer artifact replace an unstarted request, or must each distinct release intent retain a disposition?
• Decide separately whether interrupting already-running work is authorized. Do not infer permission to stop a deployment from permission to discard a stale CI check.

These are design decisions, not additional GitHub settings. The guide below follows the option-specific definitions in the captured how-to and workflow syntax. Their generic concurrency-group prose also describes running cancellation too broadly; the explicit cancel-in-progress rule and matching examples are the operative reading used here. This wording conflict was not resolved by a runtime test.[1][2]

Choose the group boundary before the queue policy

GitHub documents at most one running job or workflow in a concurrency group within the repository. Every participating writer must resolve to the intended common group. A name that is unique to a workflow or ref is useful when that work should be independent, but can defeat coordination when multiple workflows or refs deploy to the same target. Group names are case-insensitive: prod and Prod are the same group.[1][2]

Place concurrency at the top level to gate the whole workflow run, or on the deployment job to gate that participating job. The latter can leave unrelated build work outside the deployment gate. Review every path that can reach the target; sharing an environment label is not a substitute for checking the actual concurrency key and scope.[2]

A repository group is not a cross-repository or provider lock. If a CLI submits an asynchronous deployment and exits, the Actions job ending does not establish that the provider has finished. Broader serialization, duplicate handling and idempotency need their own verified provider or application contract; a group name supplies none of those guarantees. This is operational guidance, not a documented remote-lock feature.[1][2][3]

Choose pending retention and running cancellation separately

queue: single is the documented default: at most one request can be pending, and a newly queued same-group request cancels and replaces an existing pending one. Setting cancel-in-progress: false does not change that rule. Setting it to true also cancels currently running same-group work.[1][2]

The current captured github.com documentation renders queue: max, but this guide did not verify its rollout for a particular plan, account or GitHub Enterprise Server version. Check the syntax supported by your actual platform before adopting it. If it is unavailable, do not silently substitute single when preserving distinct pending requests is a requirement.[1][2]

The ordering rule is also narrower than dispatch FIFO. GitHub describes first-in-first-out processing according to when each job or run started waiting on the group, not when its workflow was dispatched. Different start times mean dispatch order is not guaranteed. This does not promise commit order or the order in which a remote provider completes asynchronous operations.[1][2]

Completed hypothetical: A is running, B is waiting, C arrives

This example is fictional and unexecuted. One repository has one production target; every deployment job uses production-deploy. A is already running, B has started waiting, and C arrives after B. Running cancellation is disabled, the multi-pending queue has room, and B and C are distinct approved release intents rather than interchangeable snapshots.

The completed choice is max with running cancellation disabled, because B must not be superseded by C. Record A as running, B and C as retained pending intents, and their remote outcomes as not yet known. Monitor the pending bound and record any canceled arrival. This is a configuration decision with explicit expected states, not a claim that any deployment succeeded.

Do not reuse this baseline unchanged for single + true: B's arrival would already initiate A's cancellation. A separate hypothetical can have A still shutting down and B still pending when C arrives; C can then replace pending B. The exact shutdown and next-start instant are not established here. Running cancellation is a request handled through the cancellation mechanism, not proof that an already-submitted remote deployment stopped.[1][2][3]

A cancellation decision is not a remote outcome

GitHub's cancellation reference describes server and runner behavior. The server reevaluates running-job conditions; a true condition such as if: always() can let a job continue. For jobs to cancel it sends cancellation messages, and the runner signals steps marked for cancellation, escalating to termination if they do not exit. The server also has a timeout for jobs and steps marked for cancellation. Do not use the workflow label alone to infer that every job or cleanup step stopped.[3]

None of that is a provider-specific rollback receipt. A deployment service may already have accepted work before the caller is interrupted. Whether that operation continues, stops or can be safely repeated depends on that service's contract and the actual operation state. Read both the Actions state and the deployment evidence before deciding what to do next; a currently active old version alone may not rule out queued or in-flight work.[3]

Reconcile a canceled deploy before retrying

The following is proposed deployment-operations guidance, not a GitHub-mandated provider API procedure. Use only reads and recovery actions already authorized for the target. A canceled workflow does not itself authorize another deployment.

• 1. Preserve identity before taking another action: repository, workflow run/job and attempt, target, artifact or commit, and any provider operation ID or acceptance receipt. Keep the canceled run linked to its original release intent.
• 2. Read the existing Actions jobs and steps, then the provider operation using its correlated identity. Distinguish no evidence of acceptance from authoritative evidence of no effect; those are not the same finding.
• 3. Classify the remote disposition: accepted and unfinished, completed with a known result, final no-effect with no late work possible under the contract, or unknown. Check relevant queued/in-flight work as well as the active target state.
• 4. If accepted and unfinished, observe or resume tracking that same operation rather than submitting a new one. If completed, reconcile its result with the intended artifact and current target before choosing any further release or rollback.
• 5. Retry only with current deployment authority and either a verified final no-effect/no-late-work basis or an applicable, verified duplicate-handling contract. Preserve the operation identity as that contract requires; the existence of an idempotency-key field alone is not proof of safe repetition.
• 6. If the result remains unknown, hold resubmission and record the next permitted provider status read, its owner and the evidence needed to decide. Do not turn uncertainty into a new operation ID.

The recovery answer is deliberately not a fictional success: A's remote result remains unresolved, but the next action is complete and specific—track OP-A, do not duplicate it, and reconcile before another conflicting submission. Queue retention preserves a waiting intent only within its documented boundary; the deployment record must still connect that intent to its final outcome.

What a finished deployment policy must answer

• Which writers share a target, and do they resolve to one group within the repository? Name external writers that this group cannot coordinate.
• May a newer pending request supersede an older one? If not, confirm multi-pending support, account for the finite bound, and track every arrival's disposition.
• Is running cancellation authorized, and is the selected queue/cancellation combination valid? Do not equate false with preservation of pending requests.
• What evidence distinguishes provider acceptance, completion, final no-effect and an unknown result? Who performs the next permitted read when a deployment is canceled?

The useful completion criterion is a retained disposition for each intended release and a correlated remote result—not merely a green or canceled workflow. In the A/B/C example, that means explaining why B must survive C, choosing the bounded policy that can retain both, and refusing to confuse A's cancellation with proof that its provider operation ended.

Evidence limits: this guide uses three official GitHub Docs pages inspected on 15 October 2026 KST. The concurrency how-to and syntax share source material, so they are not independent runtime confirmation. The inspected github/docs source snapshot is b02077198226cf298e574613071a654c46dfa7b7; it pins source passages, not the deployed documentation's complete revision. Page publication/update dates and account rollout remain unverified. No workflows or remote deployments were executed.[1][2][3]