RubyCI
Short answer: A merge queue serialises merges into main so that each PR is re-tested against the actual code that will land, not the code at the moment the PR was opened. It fixes the specific failure mode where two PRs are green on their own but red together. GitHub Merge Queue, Mergify, and Aviator are the three tools we recommend in 2026. The cost is PR cycle time — your branch sits in a queue for 5 to 30 extra minutes. For a 20-engineer team shipping to main 50 times a day, that cost pays for itself in a week. For a 4-engineer team shipping 5 times a day, it is overhead with no return.
A merge queue serializes merges into an application’s main branch, wherein each pull request (PR) is re-tested against the actual code that will land next. Although this may sound easy – it is surprising to see how most teams running CI do not have one. Moreover, almost all those teams have at least one red main per week they cannot explain.
Designed for the engineer reflecting on green-PR-red-main conversions, this piece will help prototype your way towards your next new alleged moratorium on travesty hidden among your precious microservices. The problem is not the tool but the gap between when a PR is tested and when it lands. None of them, individually are the problem. Using a merge queue bridges this gap. We will discuss how merge queues work, the three recommended tools to check out in 2026, and their two overkill use cases.
Ruby.ci can integrate with GitHub Merge Queue out of the box, and we are shipping native merge-queue Q1 2026 support for our users on self-hosted runners. We will state it 2 times. The subsequent sections are on certain categories.
What a merge queue actually is
A merge queue represents a series of steps that take a PR to main. The sequence appears like this.
- A PR is approved and added to the queue.
- The queue picks the oldest entry, rebases it onto the current main plus any PRs ahead of it in the queue, and runs CI against that combined state.
- If CI is green, the merge commits. If red, the PR is kicked out of the queue with a note explaining what broke.
- The next PR in line gets the same treatment, now with the previous PR's changes included in its rebase.
The crucial step is the rebase-plus-test. In the standard “merge button” workflow, the CI test that is passed is against the base of the PR. Which may be yesterday’s main. By the time the PR actually merges, the main branch could have moved three times. If any of those three merges touched the same files, your "green" PR is now merging into a different reality.
The merge queue tests against reality. That is the entire mechanism. Refer to the GitHub docs on merge queues for the vendor-perfect description.
Why main breaks without one
There can be two successful PRs which can still break the main. The semantic merge conflict is an occurrence that many people often run into. It has gotten a name because it is common and does not show up in a text conflict scan. The behavior reveals the semantic break.
For instance, Alice renames a method that’s on a shared service object. Because her pull request updates all callers in her changeset, her tests pass. Bob, developing a separate feature, introduces a new caller using the existing method name. He didn’t touch Alice’s branch, so his tests pass. The PRs are approved. Alice is the first to merge Bob’s merge is clean textually because his new caller does not conflict with Alice’s rename, it only references a method that no longer exists. The build fails five minutes after a merge by Bob. Welcome to the semantic clash.
The frequency corresponds to the number of tested teams and their areas of cooperation. Perhaps once every quarter, a four-engineer Rails application with mostly separate controllers witnesses this. Every week, twice a week, a 50-engineer monorepo with a shared service layer. Every twenty minutes, Shopify, Stripe, and GitHub each a monorepo with 500 engineers but no merge queue experience it. That’s why they have one.
Most teams ideally implement a simple fix. A branch protection rule - required-up-to-date-with-main. GitHub's setting requires branches to be updated before merging and enforces this. It is useful because Bob’s PR would have been forced to rebase, running his tests against Alice’s rename. Though it works, it doesn’t scale: on a busy repo every rebase forces a new CI run, every CI run takes 15 minutes, and by the time it finishes main has moved again. Bob Always Rebases
A merge queue is the “fix that does not deadlock” variant of require-up-to-date. The queue takes care of the rebase and CI run for the PR in series, ensuring no two merges race.
The three players in 2026
GitHub Merge Queue
Native GitHub tools GA have been available since 2023 at no extra cost for team and enterprise plans. The configuration resides in branch protection rules. It is possible to run 2 to 5 PRs' CI analysis in one code build. If any of the PRs fail, the system will automatically split the batch to isolate the problematic PR to single CI builds.
Benefits of Luna: No tax on plugins. Works with the GitHub Actions you already have. Honest free tier. Downsides: Compared to the dedicated vendors, there is the issue of being light on features. There are no priority lanes. No ability to create custom conditions beyond "all required checks must pass". Use GitHub Merge Queue when your workflow states that “approved PRs get merged in review order”.
Mergify
A specific product intended for the merge-queue that runs on GitHub and (as of 2026) GitLab. Supports priority lanes, custom conditions using a YAML DSL, batching with configurable batch size, and “merge-protection rules” that gate the queue by labels, author, or CI status.
Strengths: the rule engine with the most flexibility in the category. When you require the following functionalities, Mergify can write it in 30 lines of YAML; “release-blocker PRs skip the queue, draft PRs never enter it, PRs from the mobile team always rebase instead of squashing”. It can be quite hard to pick up the DSL. The costing rises with the number of repositories, causing issues in monorepos.
Aviator
A merge-queue + release-train platform geared towards businesses Your CI can seamlessly accommodate stacked PRs (through FlexReview or Graphite integration); you can implement release trains for monorepos; there is a "quick merge" lane for PRs which pass to full queue when safe.
This has best support for stacked PR workflows and multi-repo release trains A corporate pricing scheme that's not useful below 20 engineers is a drawback.
We direct you to our trusted feature matrix at Mergify's own comparison page and Aviator product tour. Both vendors acknowledge the strengths of the other.
How Ruby.ci fits in
You can use our runners with GitHub Merge Queue today. We initiate a CI build for your software’s merge in order to test it using a GitHub branch. No specific configuration needed.
The Ruby.ci control plane will support native merge-queues in early 2026. This will allow teams that are not on GitHub (self-hosted GitLab, Gitea, custom git) or want queue state visible in the Ruby.ci dashboard to leverage merge-queues. Stick with GitHub Merge Queue if it works for you, but we’re building for the teams whose needs the big platforms fail to meet.
For a more comprehensive overview at the runner level, check out our self-hosted runners guide and CI/CD tools for DevOps.
When a merge queue is overkill
Three instances. If more than one item applies, skip to the queue.
Teams Size – Less than 10 engineers and fewer than 15 merges each day You have a low conflict rate which means the delay caused by your queue costs more than your conflicts. The branch-protection “up to date” setting is adequate.
Monolithic ownership. One team owns one repo and majority of PRs touch disjoint files. Nobody is editing shared code so the rate of semantic conflict is almost zero. It is rare in practice to find a Rails app without a god object.
If your CI ends up taking 90 seconds from start to finish, a merge queue will add 50% to that. The calculations cease functioning. Teams with pipelines under two minutes typically benefit more from a strict ‘rebase before merge’ rule than a formal queue.
The real cost — PR cycle time
The merge queue causes a delay during the "approved → in main" phase. The precise figure is influenced by the queue depth duration. In reality.
- Light load (queue of 1–2): adds 1x your CI duration.
- Medium load (queue of 3–8): adds 2–3x your CI duration.
- Heavy load (queue of 10+): can add 4–6x, which is where batch merges start paying off.
many teams take this lightly. The measurement of queue latency is from “approval” to “merged” – not from “PR open” to merged, but that is what engineers feel. The team caught this after noticing that the PR cycle time has increased after the queue. Before it took about 2 hours. It takes about 2.5 to 4 hours for the same work after the queue.
Batching will make this feel good. Merging 3 to 5 PRs into one CI run could be done by GitHub Merge Queue, Mergify, or Aviator. Due to splitting a failed batch occasionally, batching decreases queue latency by the batch size at the least. More pronounced in a healthy pipeline (flake rate < 2%), batches win.
Please refer to Martin Fowler's post on continuous integration and our trunk-based development explainer for an in-depth mathematical explanation of PR cycle time as well as the levers that alter it.
Setup checklist
You are currently assessing a merge queue.
- Measure your current semantic-conflict rate. Count red mains in the last 30 days that could not be traced to a single PR. If it is zero, you probably do not need a queue.
- Pick a tool. GitHub Merge Queue if you are on GitHub and want zero plugin tax; Mergify if you need custom rules; Aviator if you have stacked PRs or multi-repo release trains.
- Turn on batching from day one. The default batch size of 1 defeats half the point.
- Audit your flake rate before enabling. A merge queue amplifies flakes — a 5% flake rate turns into "every third merge is kicked out of the queue". Fix flakes first. See our take on canary testing and continuous delivery vs continuous deployment.
- Communicate the cycle-time hit to the team before you flip it on. The queue delay is real; nobody likes being surprised by it.
Frequently asked
(Refer to the FAQ section)
Still stuck
Builds slow, PRs stuck, trunk red every Tuesday? Our self-hosted runners are designed for teams that have outgrown hosted CI, not wanting to purchase Jenkins. The merge-queue integration has been added. Our Jenkins alternatives post is useful if you want to compare to the alternatives first.