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.

·TORS > 95% is measured and tracked on a dashboard
·Auto-approve rate (% of PRs auto-merged as Green) is tracked with a target above 60%
·Merge queue wait time is tracked with a target under 10 minutes

·Agent Autonomy Score (% of tasks completed without human intervention) is measured and broken down by task type
·Metrics trigger automated alerts when thresholds are breached (e.g., TORS drops below 95%)

Evidence

·TORS dashboard showing 95%+ with per-service breakdown
·Auto-approve rate report showing 60%+ Green target
·Merge queue wait time chart showing sub-10-minute target

What It Is

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.

Why It Matters

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

Getting Started

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.
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.
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.
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.
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.
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.

Tip

Merge queue batching is the highest-leverage optimization for queue wait time. A queue that processes 1 PR every 5 minutes (5 min CI run) will struggle to handle 20 PRs/hour. A queue that processes 8 PRs per batch every 5 minutes (same CI run, 8x the throughput) handles 96 PRs/hour. Enable batching before adding more runners - it's free throughput that the queue tooling supports natively.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team is producing PRs faster than ever but deployment frequency hasn't improved proportionally. He investigates and finds that PRs are sitting in the merge queue for 40-60 minutes after CI passes. The bottleneck is the merge queue, not development speed.

What Bob should do: Bob should put merge queue performance on the platform team's roadmap as a P0 item. The specific fixes: (1) enable batch processing in the merge queue configuration (one configuration change, 5 minutes of work), (2) provision dedicated merge queue runners so the queue isn't competing with branch CI for capacity, (3) reduce the merge queue CI validation to a 3-minute smoke test rather than a full 20-minute suite. These three changes, implementable in one sprint, should reduce merge queue wait from 40-60 minutes to under 10 minutes. Bob should measure delivery frequency (PRs merged per day) before and after to quantify the impact - the improvement will be immediate and significant.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah is building the full delivery pipeline latency breakdown for the quarterly report: time in development, time waiting for CI, time in review queue, and time in merge queue. She wants to show where the time actually goes so the team can prioritize improvements correctly.

What Sarah should do: Sarah should build a waterfall chart showing the average time spent in each stage for the last 100 merged PRs: development time (branch created to PR opened), CI wait time (PR opened to CI green), review time (CI green to approved), and merge queue time (approved to merged). For most L4 teams, the waterfall will reveal a surprising finding: development time and CI time are well-optimized, but review time and merge queue time are the dominant stages. This visualization tells the story more compellingly than numbers alone. Sarah should present it as "here is where our delivery time actually goes" and use it to prioritize the review process and merge queue optimizations that will have the biggest impact on end-to-end delivery speed.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has optimized every stage of the delivery pipeline for his agent workflows. His agents produce PRs in 15 minutes, CI runs in 3 minutes, auto-approve handles 75% of his PRs, and his merge queue wait averages 4 minutes. His end-to-end delivery time from task assignment to production deploy is typically under 25 minutes for simple tasks.

What Victor should do: Victor should document his full pipeline configuration as a reference implementation for the team. The specific configuration details - which merge queue tool, how batch size is tuned, how merge queue runners are provisioned, how the smoke test CI job is structured separately from the full test suite CI job - are the implementation details that other teams need to replicate his results. Victor should also run a "delivery pipeline audit" for two other teams: spend two hours with each team pulling their waterfall data, identifying the bottleneck stage, and designing the specific fix for that stage. The consulting-style engagement is more impactful than documentation alone because it applies the framework to real data rather than leaving teams to figure out the application themselves.

What Victor should do - role-specific action plan