Plumb

Dependabot PR responsiveness

Checks how long the oldest open Dependabot pull requests have been waiting, with a shorter allowance for security fixes.
category
security
weight
7
applies to
GitHub repositories only

How Plumb checks this

What is inspected, and how the result is decided.

An automated update tool only helps if its pull requests get reviewed and merged. Dependabot pull requests left open for months mean fixes are known but not shipped, and the gap keeps growing as more releases pile up. Security fixes are the urgent case, because they address a published vulnerability.

Plumb lists the repository's open pull requests authored by Dependabot and sorts them into two groups. A pull request whose description mentions a CVE or GHSA identifier is a security update. Everything else is a general update. For each group only the oldest open pull request matters.

Security updates pass when the oldest is 14 days old or less, earn 70 percent credit up to 30 days, 30 percent credit up to 90 days, and fail beyond 90 days. General updates pass up to 30 days, earn 70 percent credit up to 60 days, 30 percent credit up to 180 days, and fail beyond 180 days. The final result is whichever group scored worse. A repository with no open Dependabot pull requests passes. The check only runs for repositories hosted on GitHub.

Doing it well

Why this matters

Dependabot only helps if its pull requests get merged. Each open pull request is a fix or an improvement that exists but has not shipped. Left alone, they pile up, the dependency drifts further from current, and the eventual catch-up becomes a bigger, riskier change. Pull requests that reference a security advisory are the urgent ones: while they wait, every user of the package is exposed to a published vulnerability.

What good looks like

  • Security update pull requests are merged within two weeks.
  • Regular version bumps are merged within a month.
  • The list of open Dependabot pull requests is short and recent.

How to do it

Make a routine

Pick a regular moment, weekly works for most projects, to go through open Dependabot pull requests. Merge the ones with green checks. Look into the ones that fail.

Let CI do the checking

A good test suite turns each pull request into a yes or no. If a dependency bump passes the tests, merging it is low risk. Investing in tests pays back every week in faster reviews.

Group related updates

A dozen small pull requests are harder to face than one. Dependabot can combine updates into groups:

version: 2
updates:
  - package-ecosystem: composer
    directory: /
    schedule:
      interval: weekly
    groups:
      dev-dependencies:
        dependency-type: development
      production-minor-and-patch:
        dependency-type: production
        update-types: [minor, patch]

Auto-merge the safe ones

For patch and minor updates that pass CI, you can let GitHub merge automatically. Turn on "Allow auto-merge" in the repository settings and add a small workflow that approves and enables auto-merge for Dependabot pull requests when the update is minor or patch. GitHub's documentation has a ready-made example.

Close what you will not merge

If an update cannot be merged, say why in a comment and close it, or tell Dependabot to skip that version with @dependabot ignore this minor version. An open pull request that will never be merged is noise that hides the ones that matter.

Things to watch for

  • Security pull requests waiting behind ordinary ones. Dependabot's security update pull requests name the advisory in their description. Do those first.
  • Failing CI that nobody investigates. A red check means the update needs a code change on your side. That is worth knowing early.
  • A frozen branch. If Dependabot's pull requests target a branch you no longer develop on, they will never merge. Point Dependabot at the right target-branch.
  • Open pull request limits. Dependabot opens at most a few pull requests at a time. If old ones stay open, new updates queue behind them.

Further reading