Skip to content

Outgrowing GitHub's merge queue?

GitHub's built-in merge queue works for small teams. But when your CI gets complex (batching, priorities, monorepo scoping, two-step validation), you need more. Here's an honest comparison.

Feature comparison

GitHub

Mergify

Speculative checks

CI batching (test multiple PRs together)

With bisect-on-failure

Two-step CI

Monorepo / scope-aware batching

PR priorities

Jump to front only
Multiple levels

Queue pause

Auto-retry on CI failure

Custom merge conditions

Rich rule engine

Queue stats dashboard

Slack notifications (queue activity)

Full event log

Monitoring integrations (Datadog)

CI Insights (job health, auto-retry)

Included

Test Insights (flaky detection, quarantine)

Included

Merge Protections (freezes, dependencies)

Included

Used by platform teams at

From fast-moving startups to well-known enterprises

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

Tomasz Biernacki

Quality Assurance Engineer at Pitch

What changes when you switch

Concrete differences that show up the day after migration, from queue visibility to merge correctness.

Live queue visibility

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

GitHub Merge Queue

Add metrics endpoint queued
Fix billing edge case queued
Bump deps running
Refactor scheduler queued
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

Throughput n/a
Avg. wait time n/a
CI failure rate n/a
Batch outcomes n/a
Queue health n/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 1 CI run #1 → ✓
PR 2 CI run #2 → ✓
PR 3 CI run #3 → ✓

3 CI runs

One 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 marked "merge immediately"

After

[D, A, B, C]

A, B, C rebuild checks from scratch

All-or-nothing

Mergify

Urgent
PR
High
PR PR
Default
PR PR PR
Low
PR

Routed by labels or rules

Predictable order

Monorepo / scope-aware queueing

PRs in unrelated services shouldn't block each other.

GitHub Merge Queue

PR frontend
PR frontend
PR billing
PR billing
PR infra
PR infra

One linear queue

Unrelated PRs block each other

Mergify

frontend
PR
PR
billing
PR
PR
infra
PR
PR

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

Slack alerts n/a
Datadog metrics n/a
REST API n/a

No integrations beyond GitHub

Limited to GitHub UI

Mergify

Slack alerts
Datadog metrics
REST API

Built-in integrations

Wired into your tooling

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

Paco Sevilla

DevOps Engineer at DeepDrive

Easy to set up, works alongside GitHub

You can test Mergify without removing GitHub's merge queue.
No migration needed, just add and compare.

1

Install the GitHub App

One click from the GitHub Marketplace. Takes under 5 minutes to set up.

2

Configure with YAML

Define your merge rules in a simple YAML file that lives in your repository.

3

Merge with confidence

Start merging faster with batching, priorities, auto-retry, and full queue visibility.

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.

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.

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.

Try the alternative to GitHub's merge queue

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

Mergify Merge Queue dashboard, full size
Merge Queue statistics dashboard, full size