Mergify vs GitHub merge queue

You turned on GitHub's merge queue.Now one red run restarts the whole line.

When a queued pull request fails, even on a flaky test, GitHub kicks it out and every run behind it starts over. Mergify tests pull requests in batches, finds the culprit when a batch fails, and keeps known flaky tests from ejecting anyone.

Start a free 14-day trial See the comparison

Used by the platform teams that ship fast and keep CI green

What GitHub does well, and where it stops

GitHub

Mergify

Tests each PR against the latest base and the PRs ahead of it

Several merge groups under test in parallel

Merges several PRs at once

Queue CI runs for 8 queued PRs

8, one per PR

As few as 1, with batching

When a run fails

Failing PR removed, rest rebuilt

Batch split to find the culprit

Lighter checks on the PR, full suite in the queue

Same required checks for both

Urgent PRs

Jump to top, in-flight PRs rebuild

Priority levels by label or rule

Monorepo scopes, parallel queues

–

Retry a job that failed for a transient reason

–

CI Insights

Flaky tests quarantined so they stop ejecting PRs

–

Test Engine

Queue pause and scheduled freezes

–

Queue analytics and event log

–

Slack and Datadog integrations

–

Price

Included with GitHub

Free for small teams, then per contributor

Get started

What GitHub does well, and where it stops

GitHub

Mergify

Tests each PR against the latest base and the PRs ahead of it

Several merge groups under test in parallel

Merges several PRs at once

Queue CI runs for 8 queued PRs

8, one per PR

As few as 1, with batching

When a run fails

Failing PR removed, rest rebuilt

Batch split to find the culprit

Lighter checks on the PR, full suite in the queue

Same required checks for both

Urgent PRs

Jump to top, in-flight PRs rebuild

Priority levels by label or rule

Monorepo scopes, parallel queues

–

Retry a job that failed for a transient reason

–

CI Insights

Flaky tests quarantined so they stop ejecting PRs

–

Test Engine

Queue pause and scheduled freezes

–

Queue analytics and event log

–

Slack and Datadog integrations

–

Price

Included with GitHub

Free for small teams, then per contributor

Get started

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, AheadComputing

When GitHub's merge queue is enough

Be honest with yourself. If these describe your team, the built-in option works fine:

Small team (fewer than 10 engineers)
Simple CI pipeline (single workflow, under 15 minutes)
Low PR volume (fewer than 20 per day)
No monorepo complexity
No need for CI batching to reduce costs

When you need Mergify

If any of these sound familiar, you've outgrown the built-in queue:

Team is growing (20+ engineers contributing daily)
CI is expensive and you need batching to reduce costs
Monorepo with multiple scopes and services
Hotfixes should automatically jump the queue based on labels or rules
Two-step CI: light checks on push, heavy checks in queue
Flaky tests are eating developer time
You need merge freezes and scheduling
CI runs exceed 30 minutes and reruns are costly

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

Quality Assurance Engineer at Pitch

What changes when you switch

The table in pictures. Each panel is something you notice the first week, starting with what the queue sees.

Live queue visibility

What's running, what's waiting, and why, at a glance.

GitHub Merge Queue

Add metrics endpointqueued

Fix billing edge casequeued

Bump depsrunning

Refactor schedulerqueued

PR list, no context

Mergify

See the queue in real time

Queue analytics

Throughput, wait times, batch outcomes, CI failure rate, over time.

GitHub Merge Queue

Throughputn/a

Avg. wait timen/a

CI failure raten/a

Batch outcomesn/a

Queue healthn/a

No queue analytics dashboard

No historical view

Mergify

Full historical view

Flaky test handling

What happens when a flake takes down a green PR.

GitHub Merge Queue

PR enters queue

CI runs

Test flakes

PR ejected from queue

Author manually re-queues

Flakes block your team

Mergify

PR enters queue

CI runs

Test flakes

Auto-detect flake

Quarantine + auto-retry

Flakes don't block merges

CI batching

Test many PRs in one run, with bisect on failure.

GitHub Merge Queue

PR 1run #1: base + 1

PR 2run #2: base + 1 + 2

PR 3run #3: base + 1 + 2 + 3

3 CI runs

One merge group run per PR

Mergify

PR 1 + PR 2 + PR 3

1 CI run

Pass

all 3 merge

Fail

bisect, retry rest

1 CI run

One run for many PRs

Priority handling

Hotfixes should jump the line, predictably.

GitHub Merge Queue

Before

[A, B, C]

PR D jumps to the top

After

[D, A, B, C]

In-flight A, B, C rebuild from scratch

All-or-nothing

Mergify

Urgent

High

PRPR

Default

PRPRPR

Low

Routed by labels or rules

Predictable order

Monorepo / scope-aware queueing

PRs in unrelated services shouldn't block each other.

GitHub Merge Queue

PRfrontend

PRbilling

PRinfra

One linear queue

Unrelated PRs block each other

Mergify

frontend

billing

infra

Scope-aware, parallel queues

Independent scopes run in parallel

Monitoring and alerts

Stream queue events to Slack, Datadog, and your own services.

GitHub Merge Queue

# merge-queue

No messages yet

GitHub's queue does not post to Slack. It emits merge_group webhooks, and the rest is yours to build.

Build the alerts yourself

Mergify

# merge-queue

MergifyAPP09:41

Merged 3 pull requests with 1 CI run

#1421 reset password flow, #1422 reset endpoint, #1423 session expiry

MergifyAPP10:12

Batch failed, culprit found

#1430 left the queue (integration/checkout failed). #1428 and #1429 merged.

MergifyAPP11:03

test_invoice_rounding quarantined

Flaky on main. It still runs, it stops blocking merges.

MergifyAPP17:00

main is frozen for the 2.4 release

The queue keeps testing. Merges resume Monday at 09:00.

Also streams queue metrics to Datadog and events to your own services

Alerts that say what happened

Merge integrity

Your CI signs off on a SHA. The commit that lands on main should be that SHA.

GitHub Merge Queue

PR enters queue

Stage merge commit

SHA: a1b2c3d

CI passes on a1b2c3d

Server rebuilds merge

SHA: 7d8e9f0 (new)

Lands on main

SHA: 7d8e9f0

Tested SHA ≠ Merged SHA

Mergify

PR enters queue

Stage merge commit

SHA: a1b2c3d

CI passes on a1b2c3d

same SHA

Lands on main

SHA: a1b2c3d

Tested SHA = Merged SHA

When the queue tests one SHA and lands a different one, branch protection still passes and the PR shows merged. You won't notice the drift until something breaks on main for reasons that don't match the diff. By then you're hunting through merge commits to figure out which ones were corrupted.

This is not theoretical. A widely-discussed Hacker News thread walks through a real case where the native queue silently reverted merged code via this exact mechanism.

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

DevOps Engineer at DeepDrive

Switching

Same checks, one file.

The checks your branch protection requires today become the queue's merge conditions. Your workflows don't change.

Install the GitHub App on one repository. GitHub's queue keeps running the others.
Copy your required checks into merge_conditions in .mergify.yml.
Compare a week of CI runs. Queue analytics show runs per merged pull request. Switch the rest when the numbers convince you.

# .mergify.yml
queue_rules:
  - name: default
    batch_size: 8 # one CI run can validate up to 8 PRs
    merge_conditions:
      - check-success = build
      - check-success = test

scopes:
  source:
    files:
      api:
        include:
          - services/api/**
      web:
        include:
          - apps/web/**

Real teams, real results

Engineering teams we helped merge faster, safer, and cheaper

Scaling AI Hardware CI Throughput With Batch Merge & Two-Step CI

Read story →

Cerebras

350 engineers · AI Infrastructure

Scaling Monorepo CI and Improving Delivery Reliability with Mergify

Read story →

Apex Fintech Solutions

350 engineers · Financial Technology

Optimizing the release process & improving the engineers' lives

Read story →

Back Market

300 engineers · E-commerce

Boosting Developer Velocity and CI Reliability with Mergify

Read story →

PayFit

150 engineers · HR Tech

FAQ

Does Mergify replace GitHub's merge queue or work alongside it?

It replaces it. Only one queue can own merging into a given branch, so pick Mergify or GitHub's native queue per repo. You can still run Mergify on some repos and GitHub's queue on others.

Doesn't GitHub's merge queue already batch pull requests?

Partly. GitHub can merge several pull requests at once (its merge limits go from 1 to 100), and each merge group includes the pull requests ahead of it. But it still dispatches one merge group, and so one CI run, per queued pull request. GitHub's docs walk through it: pull request #2 gets its own branch containing the base, #1 and #2. Mergify can test a batch of pull requests in a single run, and splits the batch to find the culprit when it fails.

Can I evaluate Mergify without disabling GitHub's merge queue?

Yes. Install Mergify on a low-traffic repo first, leave GitHub's queue managing your busy repos, and compare for a couple of weeks. The customer stories have a few examples of teams that did exactly that.

Is the silently-reverted-code incident a real risk with GitHub's queue?

Yes, and it stems from how the queue rebuilds merge commits server-side after CI passes. The merged SHA is not the SHA your CI signed off on, so a successful queue run can still land code that was not the code under test. The original Hacker News thread documents the incident. Mergify does not rebuild the merge commit, so the tested SHA is the merged SHA.

How long does it take to migrate from GitHub merge queue to Mergify?

Most teams switch a single repo in under a day. Install the GitHub App, then commit a .mergify.yml with your queue rules. Larger setups with parallel queues take longer to design but are still day-one work, not week-one.

Will my GitHub Actions workflows need to change?

No. 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. If your existing PR CI works today, queue CI works without edits. The merge_group trigger GitHub's queue required can stay or go.

How does pricing compare?

GitHub merge queue is free, included with GitHub. Mergify is free for open-source projects and small teams; paid plans scale with active contributors. See pricing for current tiers.

Last updated: October 14, 2026

Keep the queue. Lose the wait.

All features included, up to 5 users. No credit card required.

Get started See how Merge Queue works