How would you tune a GitHub merge queue's group size, concurrency, and wait time?

## Measure before you tune Four numbers determine every setting, and none of them are guessable: 1. **Arrival rate** — merge attempts per hour at peak, not on average. Queues fail at peak. 2. **CI duration** for the required checks on a merge group, at p50 and p99. The tail matters more than the median. 3. **Failure rate** — the share of entries that are genuinely red, split from the share that are flaky. These have different fixes and must be counted separately. 4. **Runner capacity and cost** — how many concurrent jobs you can actually run, and what a wasted group costs. The core ratio is *arrivals per CI cycle*: arrival rate multiplied by CI duration. Below one, a queue is barely doing anything and simple required checks with an up-to-date requirement would serve. Around three to five, the queue is genuinely earning its keep. Well above that, no queue configuration saves you and the real answer is to make CI faster or to split the repository. ## Concurrency: how many groups in flight Concurrency is the number of merge groups GitHub may build simultaneously. It converts queue depth into parallel CI runs, so it is the knob that fixes latency. If arrivals per CI cycle is `k`, you need at least `k` groups in flight to keep the backlog from growing; below that the queue lengthens without bound at peak. Above it, you are paying for speculation that rarely pays off, and every failure discards more in-flight work. Start at roughly the measured `k`, watch queue depth over a week, and adjust. The cost is direct: a queue that is `n` deep with full concurrency runs up to `n` CI builds to land `n` changes, versus one build per change without speculation. You are buying developer latency with runner minutes, and the exchange rate should be an explicit decision, not a default. ## Group size: how many entries per run Batching several entries into one group is the opposite lever: it reduces runs. Its cost appears only on failure, and it is sharp. A red batch does not identify its culprit, so the queue must re-form smaller groups to isolate it — extra runs, extra latency, and innocent authors waiting. The expected cost of a batch scales with the probability that *any* member is red, which grows with size. So: - **Low failure rate, expensive CI** → batch more. You rarely pay the isolation cost, and you save real money. - **Non-trivial failure rate** → batch less, ideally one entry per group, so failures are attributed instantly. - **Never batch to compensate for slow CI.** That trades a latency problem for an attribution problem and usually makes both worse. ## Wait time and minimum entries A short wait before forming a group lets several arrivals batch together during busy periods. Its cost is added latency for the first arrival in a quiet period. Keep it small — on the order of a minute or two — and pair it with a minimum-entries setting so the queue does not sit waiting when only one change is present. This knob is a rounding error compared with concurrency and group size; do not spend much on it. ## Check timeout The check response timeout must exceed your p99 CI duration with margin, or you will evict entries whose runs were merely slow, which looks exactly like flakiness and sends people hunting the wrong problem. But it must not be so long that a genuinely dead pipeline wedges the queue for hours. Set it from the measured tail, and revisit it whenever CI duration changes materially. ## The precondition nobody wants to hear Flaky tests dominate all of this. In a queue, a flake does not cost one re-run — it evicts a correct pull request, discards every speculative group behind it, and returns the author to the back of the line. The cost grows with queue depth, which means it is worst exactly when the queue matters most. Before tuning anything, quarantine flaky tests and measure the residual rate. A repository above a few percent flake rate will experience the queue as an unfair random-eviction machine no matter how the knobs are set. ## Consider what runs in the group at all A legitimate lever that is often forgotten: the merge group does not have to run the same suite as the pull request. A fast, high-signal subset that catches integration conflicts can gate the queue while slower suites run on the pull request or post-merge. That reduces both latency and cost more than any knob, at the price of a narrower guarantee — decide it deliberately. ## Interview framing Refuse to give fixed numbers, and say why: the settings are a function of arrival rate, CI duration, failure rate and runner capacity, and any figure without those is cargo-culting. Then give the shape of the answer — concurrency sized to arrivals per CI cycle, group size inversely to failure rate, timeout above p99, wait time small — and name flakiness as the precondition and CI duration as the lever with the largest effect.