Why your Dependabot PRs keep failing CI, and what to do about it

You turn on Dependabot or Renovate. For a few weeks the pull requests are green and you merge them. Then a bump goes red, and nobody picks it up. A week later there are eight red PRs, and the bot is still opening more.

This is normal. It is also fixable, once you know why the PRs fail. Most of the causes fall into a short list.

Why bump PRs go red

Breaking major versions

A major version is allowed to break things. A function is renamed, a default changes, a CLI flag is removed. Your code was written against the old behaviour, so your tests fail on the new one.

The error is usually clear. The fix is usually small. But someone has to read the changelog, find the call sites and edit them. That is the work that never gets scheduled.

Peer dependency conflicts

Package A wants react@^18. You bump package B, which now wants react@^19. The install step fails before any test runs.

npm error ERESOLVE could not resolve
npm error Found: [email protected]
npm error peer react@"^19.0.0" from [email protected]

These are the hardest to fix in a PR, because the real answer often involves bumping several packages together.

Type changes

A library tightens a type, or changes a return type from string to string | undefined. Nothing breaks at run time. The TypeScript build fails. The fix is a null check, a cast, or a changed import. Small, but you have to find it.

Config changes

Linters and build tools change their config formats between majors. ESLint moving to flat config is the well-known case. The bump itself is fine, but the tool no longer reads your old config file. CI fails on lint or on build, and the error message points at the tool, not at your code.

Lockfile drift

Your lockfile and package.json disagree. Maybe someone edited one by hand. Maybe a bot rebased and resolved a conflict badly. npm ci refuses to run and says the two are out of sync.

Not the bump at all

Some red PRs are not caused by the bump. A flaky test fails. A CI runner has an outage. A registry times out. Re-running the job is the fix, and any process that treats these as code problems will waste time and produce bad changes.

What teams do today

Most teams settle on one or more of these.

• Ignore it. The PRs pile up. After a while nobody looks at the list. This is the most common outcome, and it means you stop getting updates, including security ones.
• Close and move on. The bot closes the PR when you close it, and some bots will not reopen it for that version. You have chosen to stay behind.
• Pin. You add an ignore rule for the package, or pin it to the last working version. This is a valid choice for a package you cannot upgrade yet. It should come with a note about why and a date to revisit.
• Group. Renovate and Dependabot can group related updates into one PR. This helps with peer conflicts, because the packages that need each other move together. It does not help with code changes.
• Auto-merge only green. The bot merges patch and minor bumps when CI passes, and leaves everything else for a person. This is a good rule. It also leaves the red ones exactly where they were.

None of these fix the red PR. They manage the pile. Someone still has to do the migration work for each major bump.

Where an automated fix fits

The red PR is a good target for automation because it comes with its own test. CI is red before the change and either green or red after. You do not need a model to tell you whether the change worked. You have your own checks for that.

That is the idea behind Patchlit. When a Renovate or Dependabot PR fails CI, Patchlit reads the failing job logs, the version change and the files the logs name. It writes a small change and pushes one commit to the same PR branch. Your CI runs again. Green on that commit is the result. Red means another try, up to a cap you set, and then it hands the PR back to a person.

A few details matter more than the idea itself.

• It pushes to the existing branch, so you review one PR, not two.
• It never merges anything. A person reads the diff.
• It only works from what the failure points at, not your whole repository.
• It stops and says so when a fix is not its job. The reasons are listed on the how it works page.

Type changes, renamed APIs and removed flags are the good cases. The error names the problem and the fix is a few lines.

What cannot be fixed by editing files

This part is easy to skip over, so here it is plainly.

Patchlit edits files. It does not run commands. That rules out a whole group of failures.

• Lockfile regeneration. If the fix is to run npm install and commit the new lockfile, Patchlit cannot do it. It also refuses to hand-edit a lockfile, because a hand-edited lockfile is how drift starts. It tells you and stops.
• Dependency changes. A fix that needs a new or different dependency changes package.json and the lockfile together. Patchlit only allows edits to the scripts section of package.json, because it cannot keep the lockfile in step.
• Peer conflicts. These usually need several packages bumped together and an install to check the result. That is a job for grouping rules and a person, not a file edit.
• Failures that are not the bump. Flaky tests and CI outages get reported as unrelated and left alone.

In an early look at 20 failed runs on real red bump PRs, about a fifth looked fixable by editing files. That sample was small, and we describe it as a rough guide only. The honest summary is that file edits cover a minority of red PRs, and the rest still need a person or a tool that can run commands. Running commands in a sandbox is something we are considering for later. It is not built.

A practical order of work

If your bump PRs are piling up, this order tends to work.

1. Turn on grouping for packages that move together, such as a framework and its plugins.
2. Auto-merge green patch and minor bumps, and leave the rest.
3. For each red PR, find the cause from the list above. Peer conflicts and lockfile drift need a person. Type and API changes are candidates for automation.
4. Pin what you cannot upgrade, with a written reason.
5. Whatever you automate, keep your own CI as the judge, and read the diff before you merge.

Where to read more

If you want the full loop, from the failing webhook to the final verdict, it is on the how it works page. The limits and the things Patchlit refuses to do are on the security page. Patchlit works with GitHub today, and support for other platforms is planned.