The PR Graveyard: How Much Engineering Work Dies Before It Merges?
In large engineering organizations, thousands of pull requests are closed without merging or left to go stale every year, and nobody measures the cost. Learn what engineering leaders on Reddit say about abandoned pull requests, and how Keypup MCP uses pull request state, review, size, mergeability and Jira link data to size the PR graveyard, find where work dies, and triage stale pull requests before they are lost.
TL;DR: In large engineering organizations, almost one pull request in ten is closed without ever merging, and hundreds more sit open with no commit for weeks. That work was paid for, but it never reaches customers — and no delivery metric shows it, because cycle time and throughput only count what merged. This is the PR graveyard. The Keypup MCP Server reads every pull request's state, creation, last commit, closure and merge dates, review request, first review and approval dates, lines changed, mergeability, build status, Keypup's recommended action and the Jira issues it resolves. Your AI assistant can then size the graveyard, show at which review stage abandoned work dies, track whether it's growing, link abandonment to slow reviews and oversized pull requests, and triage the stale pull requests that can still be saved.
Every engineering dashboard celebrates what shipped: merged pull requests, cycle time, deployment frequency. None of them show the other side of the ledger — the pull requests that were written, sometimes reviewed, occasionally even approved, and then quietly closed or left to rot.
The Friction: Work That Disappears Without a Trace
Every engineer has closed a pull request they spent days on. In a team of ten, that's an anecdote. In an organization of 2,000 engineers across 180 repositories, it's a hidden line item worth millions — and it stays hidden for structural reasons:
Delivery metrics only count survivors. Cycle time, lead time and throughput are calculated on merged pull requests. An abandoned pull request simply drops out of the numbers, so the metrics look better the more work you throw away.
Closing is silent. A pull request closed without merging generates no incident, no alert and no retro. Often nobody but the author notices.
Stale is not closed. Hundreds of pull requests stay open for months, drifting away from the main branch until rebasing them costs more than rewriting them. They aren't abandoned on paper — they just never move again.
Nobody owns the graveyard. Authors assume reviewers will get to it, reviewers assume authors gave up, and managers never see the list.
The result: organizations debate review speed and pull request size endlessly, but cannot say how much work they lose every quarter because of them.
Why This Matters: The Real Cost of Abandoned Pull Requests
The Capacity Problem
If 9% of pull requests never merge, roughly 9% of the engineering effort behind them produced nothing customers can use. For a 2,000-engineer organization, that's the equivalent of a full department of engineers whose output is thrown away every year.
The Morale Problem
Few things discourage engineers faster than watching a finished pull request wait three weeks for a reviewer, conflict with the main branch and then get closed. Abandonment is a signal of review neglect, and engineers read it that way.
The Risk Problem
Abandoned pull requests often contain fixes: security patches, dependency upgrades, bug fixes that someone started and nobody finished. When they die, the problem they addressed stays in production — and the ticket that tracked it may already be marked done.
The Enterprise Discussion: What Engineering Leaders Are Actually Saying
Stale and abandoned pull requests come up again and again wherever engineering managers, staff engineers and directors at large organizations compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/EngineeringManagers, r/cto and r/devops.
"Our monorepo has over 900 open PRs. Some are two years old. Every quarter someone suggests a bot that auto-closes anything older than 30 days, and every quarter someone points out that we'd just be hiding the problem instead of understanding why the work died."
"One of my engineers spent two weeks on a refactor. It sat waiting for review from the platform team for a month, conflicted with three other changes, and she closed it. Our cycle time dashboard looked great that quarter. That's what made me angry."
Director of Engineering, Global Logistics Company (r/cto)
"I asked how much of our code never ships. Nobody could answer. We measure everything about the PRs that merge and nothing about the ones that don't — which is exactly where the waste is."
The pattern holds: everyone knows work dies in the review queue, but nobody can say how much, where, or why — because abandoned pull requests are excluded from every metric the organization watches.
How Keypup MCP Digs Up the PR Graveyard
The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the pull requests Keypup imports from GitHub, GitLab, Bitbucket and Azure DevOps, and the issues it imports from Jira. For every pull request, that includes its state (open, draft, merged, or closed without merging), repository, creation, last commit, closure and merge dates, review request, first review, approval and changes-requested dates, lines changed, mergeability (mergeable or conflicting), build status, Keypup's recommended action, and the Jira issues it resolves when the pull request references the issue key.
In the prompts below, an abandoned pull request is one closed without merging, and a stale pull request is one still open or in draft with no commit for more than 20 business days. You can pick your own thresholds; the important thing is to keep them consistent.
1. Sizing the PR Graveyard
The first question is the one nobody can answer: how much work never ships?
MCP Prompt:
For pull requests closed or merged in the last 12 months, show
how many were closed without merging, the abandonment rate,
and the total lines changed in those abandoned pull requests.
Also count the open or draft pull requests whose last commit
is more than 20 business days old.
Output: The PR Graveyard — Last 12 Months
Key Insight: Almost one pull request in ten never merges, and 1.92 million changed lines went with them. Another 612 open pull requests haven't had a commit in a month or more — the next wave of the graveyard, unless someone decides what to do with them.
2. Finding Where Abandoned Pull Requests Die
Not all abandoned work dies in the same place. The review stage a pull request reached before closure tells you whose process failed.
MCP Prompt:
For pull requests closed without merging in the last 12
months, group them by the furthest review stage they reached:
no review requested, review requested but never reviewed,
reviewed but not approved, and approved but never merged.
Show it as a donut chart.
Output: Where Abandoned Pull Requests Die
Key Insight: Two thirds of abandoned pull requests never received a single review. 1,045 were waiting on a reviewer when they were closed. And 465 were approved, yet never merged — work that was finished and signed off, then lost.
3. Tracking Whether the Graveyard Is Growing
A single number is a baseline. A trend tells you whether the problem is getting worse while your other metrics improve.
MCP Prompt:
By quarter of closure over the last six quarters, plot the
share of closed pull requests that were closed without
merging as a line, and the lines changed in those abandoned
pull requests as bars.
Output: Is the Graveyard Growing?
Key Insight: The abandonment rate rose from 7.1% to 10.4% in six quarters, and abandoned lines per quarter grew by a third. Merged throughput kept rising over the same period, so the growing share of work that never shipped stayed invisible.
4. Linking Abandonment to Slow Reviews
If most abandoned pull requests were never reviewed, review speed is the obvious suspect. A scatter plot across repositories tests it.
MCP Prompt:
For the 11 repositories with the most pull requests closed in
the last 12 months, plot the median business hours from
review request to first review against the abandonment rate,
with bubble size showing the number of pull requests closed
without merging.
Output: Slow Reviews, Dead Pull Requests
Key Insight: Every repository with a median first-review wait above 24 business hours abandons more than 14% of its pull requests; every one under 12 hours stays below 8%. The longer a pull request waits for a first look, the more likely it is to be closed without merging. This is a correlation across repositories, not proof of cause — but it tells you where to look first.
5. Seeing How Size Drives Abandonment
Review wait isn't the only factor. Large pull requests are harder to review, so they wait longer and conflict more.
MCP Prompt:
Group pull requests closed in the last 12 months into size
buckets by lines changed. For each bucket, show the
abandonment rate as columns, and what share of all lines
changed in abandoned pull requests it represents.
Output: Big Pull Requests Die More Often
Key Insight: A pull request over 1,000 lines is almost six times more likely to be abandoned than one under 50 lines, and those large pull requests hold 54% of all abandoned lines. Splitting work into smaller pull requests is the cheapest way to shrink the graveyard.
6. Triaging the Stale Pull Requests You Can Still Save
Abandoned pull requests are lost. Stale ones aren't — yet. Keypup's recommended action tells you what each one is waiting for.
MCP Prompt:
For open or draft pull requests with no commit in more than
20 business days, group them by Keypup's recommended action
and show the count and lines changed for each as a treemap.
Output: Triage the 612 Stale Pull Requests
Key Insight: 39% of stale pull requests are stuck because nobody was ever asked to review them, and 54 are already approved and only need someone to press merge. The 141 that need a rebase hold the most code — 96k lines — and get harder to save every week.
7. Building a PR Graveyard Scorecard per Repository
The last step turns the analysis into something each repository owner can act on.
MCP Prompt:
For the six repositories with the most pull requests closed
without merging in the last 12 months, show: abandoned pull
requests, abandonment rate, lines changed in them, share
never reviewed, median business hours to first review, open
pull requests with no commit in 20+ business days, and share
of abandoned pull requests linked to a Jira issue.
Output: PR Graveyard Scorecard by Repository
Repository
Abandoned PRs
Abandon Rate
Lines Lost
Never Reviewed
1st Review Wait (h)
Stale Open Now
Linked to Jira
core-platform
412
16.2%
318k
71%
31.9
104
22%
data-pipeline
251
14.6%
214k
68%
27.3
77
18%
mobile-app
236
7.4%
142k
49%
12.4
41
61%
payments-api
198
9.1%
167k
55%
16.8
52
47%
infra-terraform
187
19.8%
96k
74%
36.4
63
9%
billing-engine
164
11.8%
131k
61%
21.5
38
39%
Key Insight: Infra-terraform and core-platform abandon the most work and review it the slowest, and fewer than one in four of their abandoned pull requests is linked to a Jira issue. If their teams reference Jira keys consistently, most of that work was never reviewed and never planned in Jira — so nobody missed it when it disappeared.
The Technical Implementation: What Keypup MCP Actually Reads
Every number above comes from pull request and issue data Keypup already imports. It helps to be precise about what that data is — and what it isn't.
"Abandoned" Means Closed Without Merging
Keypup records each pull request's state: open, draft, merged, or closed without merging. The abandonment rate is pull requests closed without merging divided by all pull requests closed or merged in the period. Keypup doesn't know why a pull request was closed: one replaced by a new pull request, or split into several, counts as abandoned too. Read the rate as an upper bound on wasted work, and compare it across repositories and quarters rather than in absolute terms.
"Stale" Comes From the Last Commit Date
A stale pull request is open or in draft, with its last commit older than your threshold. Comments and reviews don't reset it: a pull request that's been discussed for a month without a new commit still counts as stale.
Review Stages Come From Review Dates
The furthest stage reached uses the review request date, the first review submitted date, the approval date and the changes-requested date of each pull request. Time to first review is the business hours between the review request and the first review. A pull request with no review request recorded falls in "no review requested", which depends on teams using their Git platform's review request feature.
Triage Uses Keypup's Recommended Action
Each open pull request has a recommended action computed by Keypup from its review, approval, build and mergeability state — assign reviewer, review, rebase, fix build, merge and so on — along with its mergeability and build status. That's what makes stale pull requests actionable rather than just countable.
Jira Links Depend on Referencing Issue Keys
The "Linked to Jira" column uses the Jira issues a pull request resolves. Keypup links them when the pull request references the Jira issue key. If your teams don't reference keys consistently, a low linked share may mean missing references rather than unplanned work.
Real-World Impact: Enterprise Case Studies
Case Study 1: Global Financial Services Group
Before Keypup MCP:
1,600 engineers across 210 repositories
More than 1,100 open pull requests, the oldest over two years old
A proposal on the table to auto-close everything older than 30 days
After Keypup MCP:
The graveyard prompt sized the problem: 11% of pull requests closed without merging, two thirds of them never reviewed
The triage treemap replaced the auto-close bot: 70 approved pull requests were merged in a week, and pull requests needing a reviewer were routed to repository owners
The abandonment rate fell from 11% to 6% in three quarters after the organization set a first-review target of one business day
"We were about to automate the problem away with a bot that closes old pull requests. The data showed most of them had never been looked at. We didn't have an author problem — we had a review problem, and the bot would have buried it."
— CTO, Global Financial Services Group
Case Study 2: Enterprise Healthcare Platform
Before Keypup MCP:
Platform repositories routinely received pull requests of 1,500 lines or more
Cycle time dashboards showed steady improvement
Engineers reported frustration with reviews in the quarterly survey
After Keypup MCP:
The size chart showed pull requests over 1,000 lines were abandoned five times more often than small ones
A 400-line soft limit was agreed for platform repositories, with exceptions discussed upfront
Abandoned lines per quarter dropped by 40%, and the repository scorecard became part of the monthly platform review
"Our cycle time looked great because it only counted the pull requests that survived. Once we saw how much work was dying in review, the conversation about pull request size stopped being about style and started being about money."
— VP Engineering, Enterprise Healthcare Platform
Implementation: Getting Started with Keypup MCP
1. Connect Your Git Platform and Jira
Connect GitHub, GitLab, Bitbucket or Azure DevOps, plus Jira, to Keypup. Pull requests, their states, dates, reviews, sizes, mergeability and build status are imported automatically, along with the Jira issues pull requests reference.
2. Agree on Your Definitions
Decide what counts as abandoned (closed without merging) and stale (for example, no commit in 20 business days). Use the same definitions in every prompt so quarters and repositories stay comparable.
3. Use Review Requests and Jira Keys Consistently
Ask teams to request reviews through their Git platform rather than in chat, and to reference the Jira issue key in every pull request. Both make the review-stage and Jira-link analyses more accurate.
4. Connect the MCP Server to Your AI Assistant
Follow the MCP documentation to connect Keypup to Claude, ChatGPT, Cursor or any MCP-compatible assistant.
5. Set a Baseline, Then Triage Every Month
Run the graveyard and trend prompts to set a baseline. Use the scatter and size charts to decide on review-time and size targets, run the triage prompt every month to save stale pull requests before they're lost, and share the repository scorecard with repository owners.
Frequently Asked Questions
What is an abandoned pull request?
An abandoned pull request is one that was closed without being merged. Some are legitimately replaced or no longer needed, but in most organizations a large share are finished or nearly finished work that died waiting for review or after drifting too far from the main branch.
What is a good pull request abandonment rate?
There's no universal benchmark, because some closures are healthy — experiments, duplicates, superseded work. What matters is the trend and the comparison between repositories. A rising rate, or a repository far above the others, signals review or sizing problems worth investigating.
Why don't cycle time metrics show abandoned work?
Cycle time, lead time and throughput are calculated on merged pull requests. A pull request that is closed without merging drops out of those metrics entirely, so a team can improve its cycle time while throwing away more work.
Should we auto-close stale pull requests?
Auto-closing hides the symptom without fixing the cause. Before closing stale pull requests, group them by what they're waiting for — a reviewer, a rebase, a fixed build or a merge — and act on the ones that can be saved. Then fix the review and sizing issues that made them stale.
The Bottom Line
You can't reduce waste you can't see. Keypup MCP shows how much engineering work dies before it merges, and why:
✅ Sizing the PR graveyard — abandoned pull requests, lines lost and stale pull requests ✅ Finding the review stage where abandoned work dies ✅ Tracking whether the graveyard is growing while other metrics improve ✅ Linking abandonment to slow reviews and oversized pull requests ✅ Triaging stale pull requests by what they're waiting for ✅ Giving every repository a scorecard to act on
Ready to Transform Your Analytics?
Join teams already using AI to make data-driven decisions faster than
ever.
Your median cycle time looks healthy, yet every release still ends in merge conflicts, rebases and big-bang reviews. Learn what engineering leaders on Reddit say about long-lived branches and the trunk-based vs GitFlow debate at enterprise scale, and how Keypup MCP uses pull request dates, target branches, commits, reviews and mergeability to measure branch lifetime, find where branches live longest and land aging work before it drifts into conflict.
Compare the 6 best engineering metrics tools for multi-team benchmarking in 2026 — Keypup, LinearB, Swarmia, Jellyfish, Faros and Appfire Flow — on cross-team benchmarking, org-level rollups, DORA Metrics, Git-to-ticketing linking, custom KPIs, AI capabilities and data security. See how to compare teams on equal terms and find where your delivery process is broken.
Enterprises hire hundreds of engineers a year, but almost none can say how long it takes them to ship at full speed, where they get stuck, or whether onboarding is improving. Learn what engineering leaders on Reddit say about the onboarding ramp-up tax, and how Keypup MCP uses pull request, review and Jira data to measure time to first merge, ramp-up curves, review friction and onboarding load.
