Will a serial queue keep up?

Imagine your team finishing a round of reviews. Several pull requests are approved, and everyone wants their changes on main. One developer updates a branch and waits for CI. Another asks whether it’s their turn to merge.

A merge queue takes over that coordination. In a serial queue, one pull request goes through validation at a time. That makes the order easy to follow, but every PR behind it has to wait for that turn to finish.

For a team with quick checks and occasional merges, the wait may barely matter. With a longer pipeline or a burst of approved PRs, it can stretch across the afternoon. Before choosing a serial queue, estimate how much work it can clear during your busiest hour. Start with the time one PR occupies the queue.

Start with the full occupied time

Let T be the minutes from beginning a candidate’s preparation until the queue can advance. Then ideal capacity is 60 / T candidates per hour. The model assumes a continuously supplied queue, one PR per candidate, successful checks, and no overlapping validation.

If required jobs run in parallel, use elapsed time until the last required result, rather than adding every job’s duration. Include runner waiting, branch preparation, and the time needed to observe completion.

Actual merged PRs can be lower: failed candidates consume time without producing a merge, and an empty queue does not produce work merely because capacity is available.

Worked example: ten-minute CI

Suppose required checks take ten minutes and preparation plus completion handling takes two minutes. Each successful candidate occupies twelve minutes, so the ideal ceiling is five per hour.

During an hour, four passing candidates and one failing candidate each consume twelve minutes. That hour produces four merges, despite occupying the queue continuously. This example assumes equal duration for passing and failing runs; measure your own failure behavior.

Reducing check time from ten to eight minutes, with overhead unchanged, raises ideal capacity from five to six candidates per hour. Adding more runners only helps this serial model if runner availability or job execution is part of the measured bottleneck.

Daily averages can hide an afternoon queue

Twenty PRs over eight hours average 2.5 per hour. A five-per-hour queue appears sufficient. But if eight ready PRs arrive together after a review session, the last candidate completes after 96 minutes in the twelve-minute model.

That is 84 minutes waiting plus twelve minutes being processed, assuming an initially empty queue, no failures, no priority changes, and uninterrupted execution. It is a deterministic example, not a prediction of average waiting time.

Inspect the busiest merge windows as well as the daily total. Leave capacity for retries and bursts rather than scheduling the queue at its theoretical maximum all day.

A one-week measurement worksheet

1. Record ready times. When did each PR become approved and ready for validation? Opening time includes unrelated review delays.
2. Record elapsed checks. Measure wall-clock duration for the required set, including runner waits.
3. Separate overhead. Track preparation and time between the final result and the next candidate starting.
4. Count unsuccessful attempts. Keep failures, retries, and conflicts visible rather than counting only merges.
5. Inspect bursts. Compare arrivals and completions in the busiest hour, and note the longest wait.

Use typical duration for an initial estimate and repeat the calculation with a slower observed duration. That gives two explicit scenarios without pretending a short sample establishes a reliable long-term percentile.

Choose based on the bottleneck

A serial queue is a reasonable candidate when peak demand fits its measured capacity and waiting stays acceptable. If it does not, compare faster required checks, less coordination overhead, batching, or speculative validation.

Batching and concurrency change the model. They can increase throughput, but failures and retesting also change cost and latency. Mergify’s performance guide discusses those configuration tradeoffs. GitHub documents its native queue’s controls.

MergeRamp focuses on a serial workflow. Use these calculations to assess whether that approach fits your workload, then compare GitHub Team options and review MergeRamp pricing. The illustrative queue demo shows the coordination concept; it is not a throughput benchmark.