Your PRs Are Approved. Why Aren't They Merging?
Everyone watches review latency. Almost nobody watches the gap between the green checkmark and the merge. Across public organizations showcases, median approval-to-merge is minutes, but the P90 tail runs hours to over a day, and GitQuick's Merge Pipeline Friction signal fires on every one of them.
By Ahmad Hajjar
Your team reviews a pull request, someone clicks approve, and everyone moves on. As far as the review process is concerned, the work is done.
But the code hasn't shipped yet.
Between that green checkmark and the moment the PR lands on main, there is a segment of the pipeline almost nobody instruments: approval-to-merge time. Most teams watch how long PRs wait for review. Very few watch how long PRs wait after review, and that gap is where a healthy-looking process quietly stops delivering.
Why this segment matters now
The industry spent the last two years arguing about whether AI made engineers faster at writing code. It did. The more useful question is what happens downstream.
The CEPR/NBER study of 100,000+ GitHub developers found autonomous agents raised commit activity roughly 180%, while releases rose only about 30%. Writing got faster. Shipping did not. GitLab's 2026 AI Accountability Report, based on 1,528 DevSecOps professionals, reported 85% agree the bottleneck has shifted from writing code to reviewing and validating it.
"Validating" is the word that matters. DORA's lead time for changes, the metric most engineering orgs quote, measures time from commit to production, which includes everything after approval: CI, merge queues, release gates. When more PRs pour into a fixed merge pipeline, the post-approval segment is one of the first places delivery stalls. It just doesn't show up in the metric almost everyone actually looks at: time to first review.
What approval-to-merge time measures
GitQuick isolates this segment with a dedicated metric:
Approval-to-merge time =
merged_at − last_approval_at
Only merged PRs with a recorded approval contribute. It deliberately separates "waiting to merge" from review latency, so you can tell the difference between reviewers are slow and review is fine, but landing the code is slow. Those are different problems with different fixes, and conflating them sends you hiring reviewers when the real culprit is a flaky CI stage.
What the showcase data shows
Here is approval-to-merge across ten public organizations, using one-month GitQuick showcase windows in July 2026, same pipeline, public GitHub metadata only.
| Org | Median | P90 | P90 ÷ median | Median merge |
|---|---|---|---|---|
| Microsoft | 3 min | 5.1h | ~100× | 2.6h |
| Apple | 10 min | 14.9h | ~88× | 12.9h |
| Netflix | 19 min | 24.8h (1.0d) | ~78× | 3.3h |
| Rust | 26 min | 31.6h (1.3d) | ~74× | 12.4h |
| 17 min | 16.5h | ~57× | 8.5h | |
| Meta Open Source | 12 min | 10.2h | ~51× | 7.8h |
| AWS | 9 min | 7.1h | ~47× | 4.9h |
| Uber | 56 min | 26.6h (1.1d) | ~29× | 20.2h |
| Google Cloud | 11 min | 4.7h | ~25× | 2.9h |
| Kubernetes | 46 min | 14.0h | ~18× | 12.2h |
Live data from git-quick.dev/showcase.
One pattern dominates the table.
The median is lying to you here more than anywhere else
At the median, every one of these orgs merges within an hour of approval most within minutes. If you glanced at the median alone, you'd conclude the merge step is instant and move on.
Then look at P90. Approved PRs at Rust, Uber, and Netflix regularly sit more than a full day after their last approval before landing. At Microsoft, the median is three minutes but the 90th percentile is over five hours, a ~100× gap between the typical PR and the slow tail.
That spread is the whole story. A fast median tells you the happy path works. It tells you nothing about the PR that got approved Friday afternoon, waited on a flaky integration test, and merged Monday. Multiply that across a team and the drag on shipping cadence is real, even though "review" looks perfectly healthy.
The Merge Pipeline Friction signal
Reading P90 tables by hand doesn't scale. GitQuick's Merge Pipeline Friction signal watches this segment for you and fires on three distinct checks:
- Elevated median median approval-to-merge above 4h (critical at 16h). The merge step is slow even on the happy path.
- Tail ratio P90 more than 3× the median. A subset of approved PRs is stuck while the average looks fine.
- Dominance fraction approval-to-merge accounting for more than 40% of total time-to-merge. When it fires, review is doing its job and the post-approval wait is the cycle.
The dominance check is the one that reframes the conversation: if most of a PR's life is spent after approval, adding reviewers won't help. That's the profile you tend to see in teams with heavy merge queues, serialized release trains, or long CI pipelines, where the constraint is infrastructure, not people.
In the showcase data above, dominance never fired: post-approval time is a single-digit share of these fast orgs' cycles. What fired on every one of them was the tail-ratio rule: the friction lives in the tail, not the median.
On your own org run, each triggered card shows a Why this fired chip with the exact numbers (e.g. "P90 approval-to-merge (1.0d) is far above the median (19m)") and a drill-down of the specific PRs stuck longest after approval, each linking straight to GitHub. That last part matters: the signal doesn't just say "merges are slow", it hands you the list of approved-but-unmerged PRs to go unstick.
What to do this week
Approval-to-merge friction has a different fix than review latency. Don't reach for reviewer hiring.
- Measure the segment on its own. Pull approval-to-merge median and P90 for the last 30 days. If the P90 is many multiples of the median, you have a tail problem, not an average problem.
- Sort the tail, not the average. List the PRs that sat longest between last approval and merge. Patterns usually cluster, same CI stage, same repo, same release window.
- Audit CI on the slowest-to-merge PRs. Flaky or slow required checks are the most common cause of post-approval stalls.
- Check whether the merge queue is serializing you. Branch protection and queued merges create long post-approval waits even when every check is green.
- Enable auto-merge-on-green where it's safe. If PRs sit approved because a human has to remember to click merge, remove the human from that step.
- Watch for end-of-week approval clusters. Approvals that land Friday evening inflate approval-to-merge without any CI problem at all.
This complements what you already track. Slow first review is a reviewer-capacity story, the one we covered in Your Code Reviews Are Slower Than You Think. Slow approval-to-merge is a pipeline story. GitQuick separates them so you fix the right one, and rolls both into the Signals playbook alongside the rest of your review health.
See it on public orgs first
The Showcase is the fastest way to calibrate your intuition. Open any org, look at approval-to-merge next to time-to-merge, and notice how often the median looks great while the P90 tells a completely different story. For a related culture cut, approval-driven vs comment-driven review, see our AWS vs Google Cloud breakdown.
Then run it on your own org. Your PRs are getting approved. The question is whether they're actually landing, or quietly waiting in a tail nobody is watching.
Showcase metrics are derived from public GitHub metadata only. They reflect review-process signals, not code quality or internal engineering culture. Figures come from one-month showcase windows (July 2026) and will change as underlying data refreshes. Signal thresholds are documented in the Signals Guide. GitQuick is not affiliated with or endorsed by the organizations featured.