Merge Queue Wait < 10 min

Merge Queue Wait is the time a PR spends waiting in the merge queue after all gates pass (CI green, reviews approved, policy rules satisfied) before it is actually merged. In a perfect system this is zero - a PR that's ready to merge merges immediately. In practice, merge queues serialize merges to prevent conflicts and run final pre-merge validation, which introduces latency. The target at L4 is under 10 minutes from "queue entered" to "merged."

The merge queue is the final bottleneck in the delivery pipeline. By the time a PR enters the queue, the agent's work is done, CI has passed, and the code has been reviewed. The remaining time to merge should be a matter of seconds to minutes - just enough to run the queue's merge validation and process the PR in order. A merge queue wait of 30-60 minutes represents a system that has invested heavily in fast development (quick agents, fast CI) but has left the last mile broken.

At L4, where 50+ PRs per day may be flowing through the merge queue, the queue dynamics become critical. If each PR takes 15 minutes of CI validation to merge, and 10 PRs are queued at once, the last PR in the queue waits 2.5 hours. This is the merge queue serialization problem: the queue processes PRs sequentially (or in small batches), so queue depth * processing time = effective wait for the last PR. Optimizing merge queue wait requires both reducing per-PR processing time and enabling parallel queue processing.

Teams at L4 that haven't addressed merge queue performance find that it becomes the primary constraint on delivery frequency. An agent that produces a ready-to-merge PR in 15 minutes followed by a 60-minute wait in the merge queue has an effective delivery time of 75 minutes - not 15. The agent throughput improvement is negated by the queue bottleneck. Tracking Merge Queue Wait as an explicit metric makes this bottleneck visible and creates the organizational pressure to address it.

• Eliminates the last-mile bottleneck - after CI, review, and agent work are all optimized, the merge queue often becomes the only remaining bottleneck to delivery; tracking wait time makes it visible
• Enables reliable delivery rate commitments - a merge queue wait under 10 minutes means a PR can realistically go from "ready" to "deployed" in under 20 minutes (10 min queue + deployment time); this predictability enables more reliable sprint planning and deployment scheduling
• Reduces branch divergence - the longer a PR waits to merge, the more main branch diverges and the higher the risk of merge conflicts; short queue waits keep branch divergence minimal and eliminate most conflict resolution overhead
• Scales with agent volume - as agent-generated PR volume increases, merge queue pressure increases proportionally; teams that don't address queue performance at L4 will see it become a crisis at L5 scale
• Reflects overall pipeline health - a merge queue that consistently meets the 10-minute target means CI is fast, policies are well-designed, and queue batching is working correctly; a queue that frequently exceeds the target is a sign of systemic pipeline problems

1. Instrument queue entry and merge timestamps - Most merge queue tools (GitHub Merge Queue, Mergify, Trunk) expose timestamps for when a PR enters the queue and when it merges. Log these for every PR and compute queue wait time as the difference. Track p50, p90, and maximum queue wait weekly.
2. Identify what happens inside the queue - Not all queue time is equal. Some time is spent waiting for a runner (capacity issue). Some time is spent running pre-merge CI (pipeline duration issue). Some time is spent waiting for conflict resolution when another PR merges ahead of yours (serialization issue). Break down queue wait by cause to identify the highest-priority fix.
3. Enable parallel queue batching - Most modern merge queues support batch processing: instead of validating PRs one at a time, the queue merges groups of PRs together, running CI once against the entire batch. This dramatically reduces per-PR queue time at the cost of more complex conflict handling. Enable batching and tune batch size (typically 5-10 PRs) to balance CI frequency against wait time.
4. Ensure queue CI runs on the fastest available runners - The queue's pre-merge CI run is the gating event for merges. This is not the place to use slow shared runners. Assign dedicated, fast runners to the merge queue CI job. The throughput improvement justifies the runner cost.
5. Set queue capacity targets based on peak PR volume - Calculate your team's peak PR submission rate (probably Friday afternoon before a sprint demo, or whenever agents are most active). Ensure your queue capacity (runners, batch size, CI parallelism) can process PRs at that rate with under 10-minute waits. Size for the peak, not the average.
6. Alert when queue depth exceeds threshold - Set an alert that triggers when the merge queue depth exceeds a threshold (e.g., 15 PRs waiting). High queue depth is the leading indicator of a wait time spike before it shows up in the metric. Alert early and add runner capacity proactively rather than reactively.

Running full CI in the merge queue. If your main CI pipeline takes 20 minutes, running it again in the merge queue doubles latency. The merge queue's CI should be a targeted validation that checks for merge conflicts and runs a fast smoke test, not a full re-run of the entire test suite. The full test suite already ran on the feature branch; the merge queue just needs to verify that merging with main doesn't introduce regressions.

Not accounting for queue wait in delivery time calculations. Teams often report "time from PR creation to CI green" as their delivery metric, excluding the merge queue wait. This understates actual delivery time and hides the queue bottleneck. Always measure "time from PR creation to merged and deployed" as the end-to-end delivery metric.

Building queue capacity for current volume, not projected volume. At L4, PR volume is growing rapidly as more agents are deployed. A merge queue sized for today's 30 PRs/day will struggle in 3 months when volume has grown to 100 PRs/day. Project volume growth and size queue capacity 2-3x ahead of current needs.

Treating conflict resolution as a queue problem. When PRs conflict with each other in the queue, the queue serializes them (one must merge before the other). This is not a queue capacity problem - it's a branch management problem. Reducing the size and scope of agent PRs (smaller, more atomic changes) reduces conflict rates and makes queue serialization less of a bottleneck.

Ignoring off-hours queue buildup. Agents running overnight can submit 30-50 PRs while engineers are sleeping. These PRs queue up and create a large backlog that takes hours to process when CI starts up again in the morning. Configure the merge queue to handle off-hours batch processing or adjust agent working hours to align with CI capacity availability.