The Pending Workflow Run That GitHub Cancels

A workflow run is still in progress. Another run enters the same concurrency group and waits. Then a third arrives. By default, GitHub Actions cancels the run that was waiting and gives its pending place to the newcomer. The running workflow continues unless cancel-in-progress is enabled. GitHub documents this default and explains the separate setting for running jobs.

Which run disappears

A concurrency group allows at most one running job or workflow and, by default, one pending job or workflow. A new arrival replaces an existing pending run in that group. Setting cancel-in-progress: true also cancels the run that is already running. These are two distinct cancellation decisions, so leaving that setting off does not protect a run that is still pending. GitHub describes both behaviors.

The group name decides which runs meet. A fixed name can bring different workflows in the same repository into one group. GitHub recommends including github.workflow in the name when runs from different workflows should stay separate. A branch reference can separate them further. The concurrency guide shows this pattern.

How the queue changes it

For work where waiting runs should each get a turn, set queue: max under concurrency. GitHub says this permits up to 100 pending jobs or runs in a group; arrivals beyond a full queue are canceled. The waiting runs are processed in the order they began waiting on the group. That order can differ from workflow dispatch order. GitHub also says queue: max cannot be combined with cancel-in-progress: true. These limits are in the queueing documentation.

What to do

First, inspect the workflow or job’s concurrency block and identify its group name. Check whether that name is shared by runs that should be independent. Next, decide whether replacing an older pending run is acceptable for this work. Keep the default queue: single when the newest waiting run is the one you need. Use queue: max when earlier waiting runs must have a chance to execute, and account for its queue limit. Finally, check cancel-in-progress separately: turn it on only when canceling the active run is intended. GitHub defines each setting and its effect.