Main stays green.
Your team stays fast.
Batches that cut CI runs, a lane for each part of your monorepo, and flaky tests that stop ejecting good pull requests.
Used by the platform teams that ship fast and keep CI green
2x
merge throughput
Cerebras doubled merge throughput while cutting down on its costly 3-hour CI runs.
The problem
Your team ships faster than main can take it.
Agents open more pull requests than ever, and flaky tests haven't gone anywhere. They all land on the same queue.
Want every difference? Compare with GitHub's merge queue
How Mergify keeps your queue moving
Batching
One CI run for many pull requests
Set a batch_size and Mergify groups the pull requests that are ready into one batch, tests them together the way they will land on main, and merges them in one go. Ten pull requests can cost one CI run instead of ten.
queue_rules:
- name: default
batch_size: 4Pair it with two-step CI: light checks on every push to a pull request, the full suite only once, in the queue. Long suites stop running on code that never merges.
Fail First bisection
The fastest bisection on the market
When a batch fails, the queue splits it to find the pull request responsible. With Fail First, each half starts with the tests that broke the batch, so the guilty half fails in seconds instead of after a full run.
The innocent pull requests keep going and merge, and the culprit leaves the queue.
Anti-flake
A flaky failure doesn't eject anyone
Turn on anti-flake protection and a passing batch vouches for an earlier failing one. If a later batch containing the same changes passes, the earlier failure is treated as transient and the pull requests merge.
A real bug would fail the bigger batch too, so only flaky failures get through.
Quarantine flaky tests across your repositories with Test Engine.
Parallel lanes
Unrelated changes stop waiting on each other
Each scope gets its own lane, so a CSS change never waits for a database migration. Mergify can match file paths itself, or take the scopes your build tool computes.
scopes:
source:
files:
payments:
include: [payments/**]
web:
include: [web/**]scopes:
source:
manual:Your CI runs bazel query, nx affected, Turborepo or Pants and sends the scopes with mergify ci scopes-send or the API.
A pull request that spans two scopes waits for room in both. One that touches everything can be flagged to run on its own.
Control when code lands.
GitHub's queue can only jump a pull request to the front, and every run behind it starts over. Mergify lets you set priorities, freeze merges and wait on dependencies.
Priorities
Priority levels by label or rule. A hotfix goes ahead of the feature work queued before it.
Freezes
Freeze merges for a release or an incident, on a schedule or on the spot. The queue keeps testing, and a hotfix exception still goes through.
Depends-On and Merge-After
A Depends-On line holds a pull request until the ones it names have merged, across repositories. Merge-After holds it until a set time.
Stacked pull requests
Comment @mergifyio queue on the top pull request and the whole stack enters the queue at once. It travels in one batch and lands in order, lowest first.
Moved over from GitHub's merge queue
"Mergify gives us the control and visibility we never had with GitHub's queue. It's become our CI command center."
Ben Holtzman, Senior Design Enablement Engineer, AheadComputingSwitching from GitHub's queue
Your CI, workflows and required checks stay as they are. About five minutes for the first repository.
1 · Today
Branch ruleset · main
Require merge queueGitHub's queue runs every merge.
2 · Turn off the rule
Branch ruleset · main
Require merge queueInstall the Mergify GitHub App on the repository.
3 · Queue with Mergify
you commented now
@mergifyio queue
mergify bot commented now
Queued in the merge queue
Batch · 3 PRscheckingA .mergify.yml comes later, for batches or lanes.
Going back takes the same two steps: turn the rule back on and uninstall the App.
How it fits your setup
Mergify sits between your approved pull requests and main. Your CI keeps running the way it does today.
Source control
Your CI, unchanged
Mergify
Merge queue
approved PRs → tested batches → main
Notifications
Monitoring and automation
Safe to put in the merge path
Sign-in goes through GitHub and roles are inherited from it. Every App permission is documented.
Run Mergify Enterprise Server inside your network, with GitHub.com or GitHub Enterprise Server.
Throughput, wait times and failure rates in the dashboard, and an event log of what each pull request went through.
Real teams, real results
Engineering teams we helped merge faster, safer, and cheaper
FAQ
How is Mergify different from GitHub's native merge queue?
GitHub's queue tests each queued pull request in its own merge group, together with the ones ahead of it, and runs several groups in parallel. Mergify adds parallel queues by scope (a frontend PR does not wait behind a backend migration), batches several PRs into a single CI run and splits the batch to find the culprit when it fails, runs two-step CI (lightweight checks on PRs, full suite in the queue), and keeps known flaky tests from ejecting pull requests. See the full comparison.
How long does it take to set up?
About five minutes for the first repository, with no configuration file. Install the GitHub App, then comment @mergifyio queue on a pull request and follow it through the queue from the dashboard. Larger setups with parallel queues, custom CI integration, batching, and multi-team rules take longer to design but are still day-one work.
Can we go back to GitHub's merge queue?
Yes. Going back takes the same two steps as coming over: turn the "Require merge queue" rule back on and uninstall the GitHub App. Your CI and GitHub permissions never changed, and the .mergify.yml is a plain file you can delete.
Does Mergify work with GitHub Actions?
Yes. Mergify pushes each candidate merge to a temporary queue branch and opens a draft PR for it, so workflows you already trigger on push or pull_request run there automatically. No workflow rewrite required.
Can Mergify handle monorepos?
Yes. Your CI computes scopes with your build tool and sends them to Mergify, so the lanes track what your monorepo actually is instead of a config file someone has to keep current. Bazel, Nx, Turborepo and Pants are covered, and anything else can push its own scopes through the public API. File patterns are there as the zero-setup option when you have no build tool. Each scope gets its own lane, so a CSS change never waits behind a database migration, and a pull request whose scopes nothing else has touched merges directly without running queue CI at all.
Do I need to write YAML to use Mergify?
No. A working queue takes no configuration file at all: install the Mergify GitHub App and comment @mergifyio queue on a pull request. Mergify updates the PR against the latest main, runs the CI you already have, and merges when it passes. The .mergify.yml file comes in later, when you want parallel queues, batch sizes, priority lanes, monorepo scopes, or automatic queueing of approved PRs.
What is a merge queue?
A merge queue is a system that sits between approved pull requests and the main branch. It tests each PR against the actual state main will have at merge time, then only merges when CI passes. Main stays green even when many engineers ship in parallel.
How often does a green pull request actually break main?
It depends on team size. Across 200,000 merges from 477 organizations, a pull request that passed CI still broke main 0.77% of the time at 2 to 5 engineers (1 in 130) and 12.5% of the time once a repository passed 40 engineers (1 in 8). Private codebases hit it 5.1% of the time against 1.1% for open source. That distance between "CI passed" and "safely merged" is the validation gap, and closing it is what a merge queue does. Method and full data in the State of Merge Queues 2026.
Does Mergify work with GitHub stacked pull requests?
Yes. A pull request that belongs to a GitHub stack can enter the queue like any other, and Mergify merges the members in order, lowest first, so a stack never lands out of sequence. Mergify reads the stack from GitHub itself, whether you built it in the web UI, with gh stack, or from the mobile app, so there is nothing to configure and no marker to add by hand.
Can I freeze merges during a release or an incident?
Yes. Schedule a freeze ahead of time, or start one on the spot, and nothing matching it merges until it lifts. The queue keeps testing pull requests in the meantime, so they land the moment the freeze ends, and you can carve out an exception so a hotfix still goes through. See how to run a merge queue during a code freeze.
Can a pull request wait for another one to merge first?
Yes. Add a Depends-On line to its description and Mergify holds it until the pull requests it names have merged, including ones in other repositories. A Merge-After line holds it until a given time. See how to manage dependent PRs with Depends-On.
Does Mergify do anything besides the merge queue?
Yes, and every plan includes all of it at no extra cost. CI Insights shows which CI jobs are slow or failing and where your self-hosted runner spend goes, and Test Engine finds unreliable tests. Most teams start with the queue and turn on CI Insights once they want to know what is slowing it down.
What does Mergify cost?
Free for open-source projects and for teams up to 5 users on private repositories, with every feature included and no credit card. Max is $21 per seat per month, or $216 per seat per year, up to 100 users. Enterprise is quoted per seat and adds on-premise deployment, 24/7 support, custom data retention, and a quarterly roadmap review. See pricing for the full comparison.
Want the full picture? Read the merge queue guide or compare with GitHub's merge queue.
Last updated:
Keep main green.
Mergify merges more than half a million pull requests a month without breaking main.


