FREE TOOL / MERGE QUEUE CAPACITY CALCULATOR
More PRs.
Can your merge process keep up?
Your team finishes a round of reviews. Several PRs are ready, but each needs to pass checks against the latest main. The next change is already waiting.
A merge queue takes over the coordination. Use your CI time and busy-hour volume to see how much it can handle—and what happens when more changes arrive.
Try your workload ↓No account or repository access needed.Start with your busy hour.
The defaults are an example. Use measurements from your own repository.
Wall-clock minutes until the last required check finishes, including runner waits.
Count approved PRs ready to merge, rather than newly opened PRs. To test a busier future workload, increase this number directly.
Capacity is an ideal ceiling based on CI duration. Orchestration, failed checks and retries can reduce actual throughput.
6PRs / hour
One PR every 10 minutes, validated one at a time. All checks pass.
Your workload
4 ready PRs / hour
Below capacity
66.7% of ideal capacity
About 2 PRs per hour of headroom before retries or bursts.
Based on elapsed CI duration, including runner waits. This is not a measure of billable runner minutes.
This workload fits below the ideal ceiling. Check real bursts, failures and acceptable waiting time before deciding whether it fits your team.
A quiet day can still have a busy queue.
PRs spread through the hour can merge with little waiting. The same PRs arriving together have to take turns. Try the size of a burst your team sees after reviews.
An isolated burst joining an empty queue, with no later arrivals.
The last PR then takes 10 minutes to process. This assumes an empty queue at the start, successful checks and no interruptions.
How often does merging interrupt your team?
The starting values are an illustrative example, not industry benchmarks. Replace them with estimates from your team’s recent PRs.
Your team’s total across a typical week. This is separate from the busy-hour count above.
Average times someone switches back to update a branch, check progress, or coordinate a turn. Exclude code review and fixing failed tests.
Active coordination plus finding your place in the task you left. Exclude time CI runs unattended. Use your team’s estimate.
- Returns to ready PRs
- 200 interruptions / week
- Attention spent coordinating merges
- 10 developer-hours / week
100 PRs × 2 returns × 3 minutes = 600 minutes per week.
This estimates attention spent on your current process, not guaranteed hours saved by a queue. Each return is counted as an interruption because it pulls someone away from another task. It does not count unattended CI waiting as developer time.
Your PR is ready. It keeps pulling you back.
You’ve finished the change, got approval, and started your next task. Getting that PR onto main can still interrupt the work you’ve moved on to.
Without a queue
Your branch needs to be up to date before merging. You update it and wait for CI. Before you merge, someone else lands a change. You return to the PR, update it again, and start another round of checks. Or you ask in chat whose turn it is, then keep an eye on the result so you don’t lose your spot.
Each return means putting down your current task, remembering what the PR needs, and finding your place again afterward. The interruption can be brief and still break your concentration. More approved PRs—from people, agents, or dependency bots—can create more occasions for that coordination.
With a queue
You hand over the approved PR. The queue manages the order, updates it against main, and waits for the required checks before it can merge. You can stay with your next task instead of watching for a chance to click merge. Failed checks or conflicts can still need your attention.
A team can have plenty of CI capacity and still benefit from fewer interruptions. The waiting time above is how long a PR waits for its turn; it isn’t a measure of developer time lost. The benefit here is being able to leave routine merge coordination behind.
The interruption estimate multiplies weekly PRs by returns per PR and minutes per return. Count active coordination and finding your place in the task you left, excluding unattended CI waiting. This estimates effort in your current process, not guaranteed hours saved by a queue.
Illustrative interruption example: 100 PRs per week × two returns per PR × three minutes per return gives 200 interruptions and 600 minutes, or ten developer-hours per week. These inputs are examples, not industry benchmarks or guaranteed hours saved.
Faster coding can move the bottleneck.
AI assistants and coding agents can help a team prepare more changes. If more of those changes reach approval, your integration process has more work to do—even when the team has the same number of people.
GitHub’s 2025 Octoverse reported a 20.4% increase in pull requests created. That is platform-wide activity, not a measured AI productivity gain for your team. To plan for more changes, increase the ready PR count above to the volume you expect your team to reach.
Without a queue, a busy branch can mean repeated branch updates, another round of checks, and developers coordinating who merges next. A queue can take over that ordering and validation against the latest main. Required checks still need to catch the failures that matter.
The same pressure can come from hiring, dependency updates, or a release deadline. More PRs do not automatically mean more delivered value, and a queue does not make a slow pipeline faster.
Read GitHub’s Octoverse research →One PR at a time.
Divide the 60 minutes in an hour by your required CI duration. This gives the ideal capacity when one PR is validated at a time.
The starting values are an illustrative example: ten-minute CI and four ready PRs per hour. Edit the inputs above to calculate your team’s scenario.
With 4 ready PRs per hour, your workload uses 66.7% of that capacity.
Timing matters too. Four PRs spread across an hour can have a very different wait from four arriving together after a review session. Use the burst calculation above to see how long the last PR waits for its turn.
What this estimate includes
- One PR is checked and merged at a time. Batching and overlapping validation need a different calculation.
- Every check passes and CI takes the same time each run. Orchestration, failed checks, conflicts and retries can reduce actual throughput.
- The burst starts with an empty queue and no new arrivals. Existing work or interruptions will extend the wait.
Choose the queue your workload needs.
If demand fits with room for retries and bursts, a queue that validates one PR at a time may be a useful way to reduce manual coordination. That is the workflow MergeRamp focuses on.
If demand is already above the ceiling, compare shorter required checks, batching, or speculative validation before choosing a tool. Automating an overloaded queue will not clear its backlog.