A merge queue helps when many pull requests merge into the same branch each day, which is common when a remediation tool opens several fixes at once. It tests each change against the latest branch plus the changes ahead of it. On a quiet repository you can skip it.
What a merge queue does
GitHub describes a merge queue as automation that merges pull requests into a busy branch without letting incompatible changes break it. Each queued pull request is tested with the latest target branch and the pull requests ahead of it, then merged in first in, first out order once required checks pass.
It gives the same protection as requiring branches to be up to date before merging, without making authors update branches and rerun checks by hand.
Why fix PRs create the problem
Two fix pull requests can each pass CI alone and still fail together. Typical cases:
- Two dependency updates that share a transitive package.
- A lockfile change that conflicts with another lockfile change.
- A code fix and a version bump that touch the same module.
Without a queue, the second merge can land on a base that has moved, and the test result you relied on describes a branch that no longer exists. This is the stale check problem. Requiring up to date branches fixes it, but then every merge triggers a rebase of the others, and a bot that opens ten pull requests creates ten rounds of churn.
Do you need one
| Situation | Queue useful? |
|---|---|
| Few merges per day, one maintainer | Probably not |
| Several bot pull requests land weekly | Maybe, if conflicts recur |
| Monorepo with many teams merging daily | Yes, often |
| Grouped fix pull requests already limit volume | Less likely |
If you already group fixes into one pull request per ecosystem and cap open pull requests, volume may be low enough to skip it. See the related post on how many fix PRs a bot should have open at once.
The setup detail people miss
Your CI must run on the merge_group event. Without it, the required check is never reported and the merge fails. Add it next to the pull request trigger:
on:
pull_request:
merge_group:
With third-party CI, configure the pipeline to run on pushes to branches prefixed with the queue's temporary branch names.
There is also a bot-specific wrinkle. GitHub notes in its Dependabot automation guide that when the target branch uses a merge queue, the default workflow token cannot add pull requests to it. A token with merge permission is needed in that step, so review its scope carefully.
Steps to try one safely
- Enable the queue on a low-risk repository first.
- Add the
merge_grouptrigger to the required workflows. - Open two bot pull requests that touch the same lockfile and watch how the queue handles them.
- Check the time from approval to merge before and after. A queue adds waiting, so measure it.
- Keep the revert path ready, since a queue does not make a merged change correct.
A queue protects the base branch from combination failures. It does not judge whether a fix is right, so human review and meaningful tests stay in place.
Safeguard offers autonomous remediation with fix PRs, off by default and Manual in every category, so you control how many pull requests arrive and when.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change moves from finding to a gated decision.
Quick check
Does a merge queue replace code review?
No. It tests combinations of changes. A reviewer still decides whether the change is correct and wanted.
Why did my queued pull request fail with a missing check?
Often the workflow does not run on the merge group event, so the required check never reports. Add that trigger.
Sources
Last reviewed: 19 October 2026.
