Skip to content
Merge Queue· for teams outgrowing GitHub's

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

Cerebras doubled merge throughput while cutting down on its costly 3-hour CI runs.

Read the story

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.

SituationGitHub's merge queueMergify
More pull requestsagents open them around the clock
GitHub's merge queue: a CI run for eachCI load grows with every PR
Mergify: one run per batchmany PRs, tested together
Flaky testsa red run that isn't a bug
GitHub's merge queue: the PR is ejectedand the runs behind it restart
Mergify: it still mergesa later passing batch vouches for it
Unrelated changesa CSS fix behind a DB migration
GitHub's merge queue: one line for allthe fix restarts when the migration fails
Mergify: a lane per scopethe fix never waits

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.

.mergify.yml
queue_rules:
  - name: default
    batch_size: 4

Pair 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.

File paths
scopes:
  source:
    files:
      payments:
        include: [payments/**]
      web:
        include: [web/**]
Build graph
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

  • AheadComputing
  • Reddy
  • Unto Labs
"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, AheadComputing

Switching from GitHub's queue

Your CI, workflows and required checks stay as they are. About five minutes for the first repository.

  1. 1 · Today

    Branch ruleset · main

    Require merge queue

    GitHub's queue runs every merge.

  2. 2 · Turn off the rule

    Branch ruleset · main

    Require merge queue

    Install the Mergify GitHub App on the repository.

  3. 3 · Queue with Mergify

    you commented now

    @mergifyio queue

    mergify bot commented now

    Queued in the merge queue

    Batch · 3 PRschecking

    A .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

GitHub.comEnterprise Server

Your CI, unchanged

GitHub ActionsBuildkiteJenkinsCircleCIAzure Pipelines

Mergify

Merge queue

approved PRs → tested batches → main

Notifications

SlackChecks and comments

Monitoring and automation

DatadogREST APICLI

Safe to put in the merge path

SOC 2 Type II

Report, audit details and sub-processors on the trust portal.

Roles from GitHub

Sign-in goes through GitHub and roles are inherited from it. Every App permission is documented.

On-premise

Run Mergify Enterprise Server inside your network, with GitHub.com or GitHub Enterprise Server.

Statistics and event log

Throughput, wait times and failure rates in the dashboard, and an event log of what each pull request went through.

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.