The Dependency Bot Backlog: Why Dependabot and Renovate Pull Requests Pile Up Unmerged

The platform team turned on Dependabot across every repository two years ago. The dashboard in the security review says "automated dependency updates: enabled". Then someone opens the pull request list of the checkout service and finds 140 open bot pull requests, the oldest from last spring, a framework major with a red build at the top, and a dozen patch bumps that were merged on a Friday night without a single approval. Updates are automated. Nobody owns what happens to them.

The Friction: Automation That Produces Work Instead of Removing It

Dependency bots do exactly what they're told: watch every manifest, and open a pull request for every new version. At enterprise scale, that creates a predictable set of problems:

• Inflow scales with repositories, not with people. Ten repositories with five ecosystems each, and weekly schedules, produce hundreds of pull requests a month. Each one needs a look, a CI run, a decision.
• Not all bumps are equal. A patch bump with green CI is a one-click merge. A major bump of a framework or a build tool is a migration project disguised as a pull request. Both arrive in the same queue with the same bot avatar.
• Bots can't fix breaking changes. When a build fails or the branch conflicts, the next move is on the author. When the author is a bot, the next move is on nobody.
• Auto-merge hides review. Teams turn on auto-merge to keep up. Some of it is sensible, behind tests and branch protection. Some of it means dependency changes reach production with nobody having looked at them.

The result: an organization that can say dependency updates are automated, but can't say how many are waiting, which ones matter, or who decided to merge them.

Why This Matters: The Real Cost of the Bot Backlog

The Noise Problem

When a third of all pull requests come from bots, engineers learn to ignore them. Review notifications get filtered, bot pull requests get closed in bulk, and real upgrades get lost in the noise. The bot keeps reopening them, and the backlog keeps growing.

The Major Upgrade Cliff

Patch and minor updates are cheap if you take them continuously. Major upgrades skipped for a year become a cliff: several majors behind, deprecated APIs everywhere, and eventually an end-of-life runtime that forces an unplanned migration under pressure.

The Change Control Problem

Auditors and security teams ask who approved each change that reached production. A dependency bump changes code you ship. If it was merged by an auto-merge rule, or by an engineer who clicked merge without a review, your change control has a gap that nobody has measured.

The Enterprise Discussion: What Engineering Leaders Are Actually Saying

"Dependabot spam", "we have 300 open Renovate PRs" and "nobody wants to do the major upgrade" come up again and again wherever platform engineers, staff engineers and engineering managers compare notes. The quotes below are representative of recurring threads on r/ExperiencedDevs, r/devops, r/node and r/java.

The pattern holds: organizations turn on dependency bots and count that as dependency management, but rarely look at what happens to the pull requests the bots open, who merges them, and which upgrades are quietly abandoned.

How Keypup MCP Measures the Dependency Bot Backlog

The Keypup Model Context Protocol (MCP) Server gives your AI assistant structured access to the data Keypup imports from GitHub, GitLab, Bitbucket and Azure DevOps, and from Jira. For this analysis, what matters is that each pull request carries its author, title, source branch, repository, creation, closure and merge dates, build status, approval count, first approval date, merged-by account, requested reviewers, and Keypup's recommended action and recommended actors: who is expected to make the next move.

Three conventions make the analysis possible. A bot pull request is one authored by dependabot[bot] or renovate[bot] (add any other automation accounts you use to the prompt). The bump type is parsed from the title: Dependabot titles read "Bump package from X.Y.Z to X.Y.Z", so a major bump is one where the first number changes. Renovate's default titles don't include the source version, so for Renovate, configure it to add a major, minor or patch label to each pull request and ask the assistant to use the label instead. The package ecosystem is parsed from the Dependabot branch name, dependabot/<ecosystem>/…. All figures below cover the last 12 full months, November 2025 to October 2026, for an organization of around 1,400 engineers.

1. Sizing the Bot Backlog

The first question: how much of your pull request traffic comes from bots, and what happens to it?

MCP Prompt:

For pull requests opened in the last 12 full months, show the share
authored by dependabot[bot] or renovate[bot], how many of those were
merged, closed without merge or are still open, how many bot pull
requests are open today and their median age in business days, and
the share of merged bot pull requests with no approval. Split the
outcome by major, minor and patch bump, parsed from the title.

Output: How Big Is Our Dependency Bot Backlog?

Key Insight: Bots open almost a third of all pull requests, and fewer than half of them ever merge. Patch bumps mostly go through. Major bumps mostly die: only 11% merged, 55% were closed, and a third are still open. The upgrades that matter most are the ones the automation handles worst.

2. Tracking Whether the Backlog Is Growing

A snapshot doesn't say whether teams are keeping up. A monthly trend compares what the bots open with what teams merge.

MCP Prompt:

By month over the last 12 full months, show as bars the number of
bot pull requests opened and merged, and as a line the number of bot
pull requests still open at the end of each month, rebuilt from
their creation, closure and merge dates.

Output: Is the Bot Backlog Growing?

Key Insight: Bots open about 1,500 pull requests a month; teams merge about 680. Even with thousands closed unmerged, the open backlog grew 73% in a year. Bot inflow grows with the number of repositories and manifests. Human merge capacity doesn't, and the gap ends up as a queue nobody looks at.

3. Finding the Ecosystems That Clog the Queue

The organization-wide view hides where the problem sits. A heatmap by package ecosystem shows which kinds of updates flow and which ones stall.

MCP Prompt:

For Dependabot pull requests opened in the last 12 full months, show
as a heatmap by package ecosystem (parsed from the branch name):
pull requests opened, share merged, median business days to merge,
share closed without merge, and the share of open pull requests
whose build is failing.

Output: Which Ecosystems Clog the Queue?

Key Insight: npm generates 42% of Dependabot pull requests on its own, and JVM and .NET updates are where they stall: nuget and gradle take 6 to 7 business days to merge and more than half of their open pull requests have a failing build. GitHub Actions bumps merge in under a day with a 71% merge rate: that's the obvious candidate for grouped updates and auto-merge, which frees review attention for the ecosystems that need it.

4. Checking Who Approves Bot Pull Requests

Merging quickly is only half the story. The other half is whether anyone looked at the change before it reached the main branch.

MCP Prompt:

For bot pull requests merged in the last 12 full months, show as a
donut how they were merged: approved by a reviewer, merged by an
engineer without any approval, or merged by a bot account without
approval. Next to it, show the share merged with no approval for
patch, minor and major bumps.

Output: Who Actually Checks Bot Pull Requests Before They Merge?

Key Insight: 62% of merged bot pull requests changed dependencies with nobody approving them, including 31% of the major bumps. Auto-merging patch updates behind green CI and branch protection can be a sound, documented policy. Merging major upgrades without a reviewer is a gap in your change control, and now you can count it per repository.

5. Seeing Who Absorbs the Queue

If dependency hygiene is shared, merges should be spread across teams. A Pareto chart shows whether that's true.

MCP Prompt:

For bot pull requests merged by a person in the last 12 full months,
show a Pareto chart of the 10 engineers who merged the most, with the
cumulative share of all engineer-merged bot pull requests. Add how
many engineers merged any pull request, and how many merged at least
one bot pull request.

Output: Who Absorbs the Bot Queue?

Key Insight: Ten engineers merged 45% of all human-merged bot pull requests, out of 1,380 engineers who merged anything. Dependency hygiene isn't a team practice here: it's a side job for a handful of platform people, invisible in their objectives, and it stops the day they change teams.

6. Finding What Each Open Bot Pull Request Is Waiting For

Keypup computes a recommended action for each open pull request (assign a reviewer, review, merge, fix the build, rebase) and the people expected to take it. For bot pull requests, that shows whether the backlog is slow review or missing ownership.

MCP Prompt:

For bot pull requests open today, break them down by Keypup
recommended action as horizontal bars, with the count, the share of
the open total, and who is expected to make the next move.

Output: What Is Each Open Bot Pull Request Waiting For?

Key Insight: 85% of open bot pull requests have no engineer named as the next actor: 1,610 have no reviewer at all, and 1,930 wait on a rebase or a build fix. For all of them, Keypup puts the next move on the author, which is the bot that opened them and can't assign a reviewer or resolve a breaking change. Only 640 are sitting with a person. The backlog isn't slow review. It's missing ownership.

7. Listing the Upgrades Nobody Owns

The last step turns the analysis into a work list: the oldest significant upgrades, one per repository, with what they're waiting for.

MCP Prompt:

List the oldest open bot pull requests with a major or minor bump,
one per repository. Show the pull request, the package and versions
from the title, the bump type, age in business days, build status,
Keypup recommended action and who it is waiting on.

Output: The Upgrades Nobody Owns

Key Insight: The two oldest upgrades are framework majors with a failing build, waiting on the bot that opened them. No bot can migrate a Next.js or Spring Boot major for you. These need a Jira ticket, an owner and a slot in a sprint, not another weekly rebase. The rest of the list is cheap: a reviewer to assign, a review to finish, a merge button to press.

The Technical Implementation: What Keypup MCP Actually Reads

Every number above comes from fields Keypup already imports from your Git platforms. It helps to be precise about what they are, and what they aren't.

Bot Pull Requests Are Identified by Author

Keypup imports the author of each pull request. Dependabot and Renovate open pull requests under their own accounts, dependabot[bot] and renovate[bot] on GitHub. If you run Renovate self-hosted under a service account, or use other update tools, list those accounts in the prompt.

Bump Type and Package Come From the Title or Labels

Keypup doesn't parse package manifests. The assistant extracts the package, the source and target versions from the pull request title with a regular expression, which works with Dependabot's default "Bump package from X to Y" titles. Renovate's default titles only state the target version: configure Renovate to add an update-type label, or to include the source version in its titles, and the same analysis applies. Grouped updates that bump several packages in one pull request have no single version in the title and should be counted as their own category.

Ecosystem Comes From the Branch Name

Dependabot names its branches dependabot/<ecosystem>/<package>-<version>, and Keypup imports the source branch of each pull request. Renovate branches use a configurable prefix, renovate/ by default, and don't carry the ecosystem unless you configure them to.

Approval and Merge Path Come From Reviews and the Merged-By Account

Keypup imports each pull request's approval count and first approval date, and the account that merged it. "Merged with no approval" means no review in the approved state before the merge. Whether the merging account was a person or a bot depends on how auto-merge works on your platform: with GitHub's native auto-merge, the merged-by account is the engineer who enabled it, so the split between "engineer" and "bot account" reflects your tooling as much as your people.

Recommended Actions Are Computed From Pull Request State

Keypup's recommended action and recommended actors are derived from each open pull request's requested reviewers, review state, approvals, build status and mergeability. When no reviewer is assigned, the build fails or the branch conflicts, the next move is on the author, and when the author is a bot, no engineer is named. That's not a gap in the data, it's the finding.

What Keypup Doesn't See

Keypup doesn't import Dependabot security alerts, CVE identifiers, CVSS scores or software composition analysis results, so it can't say which open bot pull request fixes a known vulnerability, unless your teams or your bot configuration add a label such as security to those pull requests. It doesn't import deployment events either: "merged" means merged to the target branch, not deployed.

Real-World Impact: Enterprise Case Studies

Case Study 1: European Payments Provider

Before Keypup MCP:

• 1,100 engineers, 900 repositories, Dependabot enabled everywhere by a security mandate
• Security reporting tracked "Dependabot enabled" per repository, nothing else
• Two framework majors more than a year behind in customer-facing services

After Keypup MCP:

• The outcome split showed fewer than 15% of major bumps merged, and each open major with a failing build became a Jira ticket with an owning team
• The merge path donut showed most patch bumps merged with no approval, which led to a written auto-merge policy: patch updates of non-runtime dependencies only, behind required checks
• The Pareto chart showed eight engineers merging almost half of all bot pull requests; dependency maintenance became a rotating duty in each team, and the share merged by the top ten fell by half in two quarters

Case Study 2: North American Retail Technology Company

Before Keypup MCP:

• 600 engineers, Renovate across 300 repositories
• More than 2,000 open Renovate pull requests and engineers filtering bot notifications to the trash
• No view of which updates mattered and which were noise

After Keypup MCP:

• Renovate was configured to label every pull request with its update type and to include the package manager in its branch names, so the backlog could be split by major, minor and patch, and by ecosystem
• The ecosystem view showed GitHub Actions and Docker updates merging fast and npm updates drowning everything else; npm updates were grouped weekly, which cut bot inflow by more than half
• The next-action breakdown became a weekly platform review: every bot pull request without a reviewer for more than ten business days gets assigned or closed

Implementation: Getting Started with Keypup MCP

1. Connect Your Git Platforms

Connect GitHub, GitLab, Bitbucket or Azure DevOps to Keypup. Pull requests and reviews are imported automatically, across all repositories, including bot-authored ones.

2. List Your Automation Accounts

Note every account that opens or merges pull requests on its own: dependabot[bot], renovate[bot], self-hosted Renovate service accounts, merge queue apps. Include them in your prompts.

3. Make Bump Type Readable

Keep Dependabot's default titles. For Renovate, add an update-type label, or include the source version in the title, so the assistant can split major, minor and patch updates.

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. Turn the Backlog Into Decisions

Run the backlog size and trend monthly, agree on an auto-merge policy per bump type and ecosystem, and review the "upgrades nobody owns" list in your weekly platform or architecture meeting.

Frequently Asked Questions

Why do Dependabot pull requests pile up?

Because bots open pull requests faster than teams merge them, and because the bot can't resolve breaking changes. Patch updates usually merge; major updates with a failing build or a merge conflict wait for an engineer who was never assigned. The backlog grows with every new repository and ecosystem.

Should you auto-merge Dependabot or Renovate pull requests?

For patch updates with required checks and branch protection, often yes, and many organizations do. The point is to make it a deliberate, documented policy, and to measure it: how many bot pull requests merge without approval, by bump type, so major upgrades don't slip through the same path.

How do you measure dependency update health?

Look at what happens to the pull requests the bots open: the share merged, closed and still open, by major, minor and patch bump; the time to merge by ecosystem; the share merged with no approval; and how many open bot pull requests have no engineer as the next actor.

Who should own dependency upgrades?

The team that owns the repository. A Pareto chart of who merges bot pull requests usually shows a few platform engineers doing it for everyone. Rotating the duty within each team, and turning major upgrades into planned tickets, spreads the load and keeps it visible.

The Bottom Line

Turning on a dependency bot isn't dependency management. What matters is what happens to the pull requests it opens. Keypup MCP makes that visible:

✅ Sizing the bot backlog by outcome and by major, minor and patch bump ✅ Tracking whether the backlog grows month after month ✅ Finding the ecosystems where bot pull requests stall ✅ Checking who approves bot pull requests before they merge ✅ Seeing who absorbs the queue across the organization ✅ Finding what each open bot pull request waits for, and on whom ✅ Listing the upgrades nobody owns

Ready to clear your dependency bot backlog? Connect the Keypup MCP Server and ask your AI assistant.