Skip to content
Merge Queue

Main stays green.
Your team stays fast.

Two PRs pass CI. Both merge. Main breaks. Mergify tests every PR against the real state of main before it merges.

Trusted by Cerebras, Luminar, and AheadComputing on 100-to-350-engineer monorepos with multi-hour hardware tests.

Merge Queue dashboard showing batched PRs and queue activity

In one paragraph

Mergify Merge Queue rebases each pull request onto the latest main (plus any PRs ahead of it in the queue) and only merges the PR if CI passes against that combined state. Two PRs that pass CI separately can no longer break main together. See the full guide on what a merge queue does.

The bigger your team, the more it matters. Across 200,000 merges from 477 organizations, a pull request that had already passed CI still broke main 0.77% of the time at 2 to 5 engineers, and 12.5% of the time past 40 engineers. That is one merge in eight. The distance between "CI passed" and "safely merged" is the validation gap, and the queue is what closes it. Read the State of Merge Queues 2026.

Setup is one install and one comment: add the Mergify GitHub App, comment @mergifyio queue on a pull request, and it merges through the queue. No .mergify.yml to write, no CI workflow to rewrite. It is free for open source and for teams up to 5 users, then $21 per seat per month. See pricing.

PRs pass CI individually.
Together, they break main.

When PRs are developed in parallel, each passes CI against its own base. But when both merge, their combined changes conflict in ways that no diff can show. The more engineers you have, the wider that validation gap gets.

Every PR tested against the real state of main

Mergify updates each PR to the latest main and retests it before merging. If the combined state would break, Mergify catches it and notifies the author. No broken main, no manual triage.

Automatic rebase and retest

Every PR is rebased on the latest main and retested before it merges. No stale bases, no surprises.

Automatic conflict resolution

When PRs conflict, Mergify picks the right one to merge and notifies the author of the other. No manual triage needed.

Mergify is a no-brainer. If you want to have your main branch always working then you have to introduce some merge queue functionality.

Paco Sevilla

Paco Sevilla

DevOps Engineer at DeepDrive

Your CI bill keeps growing but
your merge rate doesn't

Running full CI on every pull request regardless of merge readiness wastes compute and money. Most of those runs are thrown away.

Batch processing illustration showing grouped PRs

Batch processing

Group PRs and test them together in a single CI run. If a batch fails, bisect-on-failure finds the culprit automatically.

Two-step CI illustration showing quick checks then full suite

Two-step CI

Run fast checks on every push. Save the full test suite for PRs that are actually ready to merge. Less CI waste, faster feedback.

Early on, as the team, tests, and CI complexity grew, it was quite clear that we needed an automated tool to resolve bottlenecks. Our team loves the way Mergify solved our growing pains.

Tomasz Biernacki

Tomasz Biernacki

Quality Assurance Engineer at Pitch

Your queue is the bottleneck

With 30-minute CI and a serial queue, you top out at ~48 PRs per day. In a monorepo, it's worse: unrelated changes block each other for no reason.

Your team writes code faster than the queue can merge it.

Parallel queues and scopes remove the bottleneck

Mergify tests multiple PRs concurrently against predicted future states of main. Scopes let you tag PRs by area (frontend, backend, infra, docs) so unrelated changes merge independently. A CSS fix no longer waits behind an API migration.

Speculative checks

If PR #3 depends on #1 and #2 succeeding, Mergify builds that speculative state and tests against it. No waiting in line.

Scope-based merge lanes

Scopes come from your build graph — Bazel, Nx, Turborepo, Pants, or your own tooling through the API — or from file patterns if you have no build tool. Each one is its own lane, so a CSS fix never waits behind an API migration.

Higher merge throughput

Teams go from merging 10 PRs a day to 50+ without adding CI capacity. The queue stops being the thing everyone complains about.

Already using GitHub's merge queue?

See exactly where it falls short and what Mergify adds: batching, priorities, two-step CI, monorepo scoping, and more.

See the comparison

Most teams can't explain why
their queue is slow

Mergify gives you full visibility into throughput, wait times, failure rates, and batch outcomes. You see what's slowing you down and fix it with data.

Curious what those numbers look like across the industry? Read the State of Merge Queues 2026, our report on 200,000 merges.

Merge Queue statistics dashboard showing throughput, queue health, batch outcomes, and CI failure rate trends

Your queue is only as fast as the CI under it

CI Insights sits on the same plan at no extra cost. It shows which jobs are slow or failing for no visible reason, and where your self-hosted runner budget actually goes. Fix those and the queue speeds up on its own.

See CI Insights

Built for pipelines that take hours, not minutes

Firmware builds, OS validation, hardware-in-the-loop testing, multi-stage deployments. When CI runs are expensive, every wasted minute compounds.

Long test cycles

Multi-hour pipelines make every failure expensive. Two-step CI runs lightweight checks first.

Flaky tests at scale

One intermittent failure can stall dozens of engineers. Auto-retry and quarantine keep the queue moving.

CI costs spiral

Big jobs plus reruns multiply your bill. Batch processing groups PRs together and bisects on failure to avoid waste.

Hotfixes stuck in line

A critical fix shouldn't wait behind 20 feature PRs. Priority queues let urgent changes jump ahead and merge first.

One install, one comment

You do not configure a merge queue to find out whether you want one. Nothing to write, nothing to migrate, and your existing CI keeps running exactly as it does now.

Step 1

Install the GitHub App

Authorize Mergify on the repositories you want. That alone gives you a working queue that respects the branch protections and rulesets you already have.

Step 2

Comment on a pull request

Write @mergifyio queue. Mergify updates the PR against the latest main, runs your CI on the updated code, and merges it when the checks pass.

Free for open source and for teams up to 5 users on private repositories, with every feature included. After that it is $21 per seat per month. See pricing.

Parallel queues, batching, priority lanes, and monorepo scopes live in a .mergify.yml you write when you need them. Read the setup guide.

FAQ

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 is Mergify different from GitHub's native merge queue?

Mergify supports parallel queues by scope (a frontend PR does not wait behind a backend migration), batches multiple PRs into a single CI run with automatic bisection on failure, runs two-step CI (lightweight checks on PRs, full suite in the queue), and gives you queue analytics. GitHub's native queue does none of those.

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. Mergify computes scopes from your build graph, 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.

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.

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 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, Test Insights finds unreliable tests, Merge Protections enforces rules beyond GitHub branch protection, and Stacks handles dependent pull requests. 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 against GitHub's native queue.

Last updated:

See what broken main is costing you.

Get a personalized estimate of the hours and CI minutes you're losing every month.