Merge queue reliability: a case study

const metadata = ; Trunk-based development only works when the merge queue is trustworthy. This case study follows a platform team that rebuilt queue reliability after main spent nearly four hours red on a typical week. Starting point - 120+ engineers merging through a shared queue - p95 queue wait: 38 minutes - 47% of queue failures were infrastructure or flake, not code defects - Mean time to unblock main: 2.4 hours Interventions 1. Separate signal from noise Queue failures were tagged as code, flake, or infra. Infra failures routed to platform; flake entered quarantine automatically after two identical outcomes on different commits. 2. Fail fast on infra Runner preflight checks (disk, cache, registry auth) ran before expensive test suites. Infra failures dropped from 22% of queue runs to 6%. 3. Agent-assisted triage On code failures, an investigation agent attached: failing step, log excerpt, diff summary, and last green commit. Median time-to-first-action dropped from 41 minutes to 14. Results (90 days) | Metric | Before | After | | | | | | Main red hours / week | 3.8 | 2.0 | | p95 queue duration | 38 min | 24 min | | Re-run rate | 31% | 12% | Lesson The merge queue is production. Reliability work belongs in the same budget as service uptime, not as a side project when developers complain.