Merge Queue Wait measures the time a pull request spends waiting in the merge queue after approval before it is actually integrated into the target branch. Extended queue times indicate contention on shared branches, slow CI validation, or serialization bottlenecks. Reducing this wait time shortens the gap between approval and delivery, keeping developer momentum intact.
Time spent in queue after approval. Critical bottleneck at 20+ active developers.
CRITICALLY AMPLIFIED: Expedia's shared-UI monorepo had 20+ PRs competing simultaneously — each merge invalidated all others. Queue partitioning by affected project area is essential. Without it, merge queues become the primary productivity killer.
AMPLIFIED: PR enters queue at end of developer's day → fails overnight (flaky test or conflict) → developer doesn't see failure until next morning (12h later) → resubmits → fails again while sleeping. A 30-minute fix becomes a 2-3 day merge cycle.
Queue contention is superlinear. Graphite: 10 devs queued = 45+ min wait. Expedia faced 20+ competing PRs in their shared-UI monorepo.
Direct additive component.
Unpredictable waits fragment the workday.
Watching approved PRs reset by others' failures.
Queue failures reset PR progress. Each failure = hours or days of delay before retry completes.
One flaky failure cascading-resets all queued PRs.
Larger changes conflict more with queued PRs.
Queue partitioning: PRs only compete with PRs affecting the same projects, not all PRs.
Slower human cycle times mean PRs accumulate in queues. More concurrent PRs = more conflicts and resets.