Count five things per repository per month: pull requests opened, share merged, share closed without merge, median age of open ones, and how many were security fixes. If most pull requests are merged within days, the tool is helping. If most are closed or ignored, it is noise.
Why measure at all
The documentation of one update bot admits that definitions of noise differ: for some people it is a notification email, for others it is too many commits on the base branch. So an argument about noise goes nowhere without numbers. Counting turns it into a decision about settings.
The same documentation describes the arc many teams follow: delight in the first days, then a feeling of being overwhelmed after a few weeks, when the defaults raise a pull request for every update to every dependency.
The five measures
| Measure | How to count | What it tells you |
|---|---|---|
| Pull requests opened | Per repository, per month | Raw volume against your open cap |
| Merge rate | Merged divided by opened | Whether the pull requests are wanted |
| Closed without merge | Closed unmerged divided by opened | Waste, or rules that are missing |
| Median age of open pull requests | Days since opened | Backlog and ignored work |
| Security share | Security pull requests over all | Whether urgent work stands out |
Add one more if you can: median time to merge for security fixes. That is your real exposure window from the tool's side.
How to read the numbers
- A high merge rate and short age means the settings fit. Leave them alone.
- A low merge rate with many closed pull requests means you are asked to review things you never wanted. Add ignore rules with reasons, narrow groups, or require approval for majors. Beware: in some tools a closed pull request is recreated, which inflates the count. Our post on why closed pull requests come back explains it.
- A high median age with a low close rate means pull requests sit. Lower the open cap so the queue is honest, or assign owners.
- A tiny security share inside a flood means urgent fixes are buried. Label and sort them, and check that security pull requests bypass caps.
- A spike on day one is normal during onboarding. Look at week three.
Where noise really comes from
The noise guide of that bot lists the levers: group related packages, but know that grouping makes breakage harder to trace and blocks the rest of a group when one fails; schedule runs outside working hours; and be selective instead of applying blanket rules. It also notes that bot pull requests can pile up after one merge because lockfile conflicts force rebases.
Add a human cause: ownership. A pull request nobody owns ages no matter how well you tune the tool. See why developers ignore bot pull requests.
Avoid gaming the metric
Zero open pull requests is not the goal. You can reach it by ignoring everything. Pair noise measures with a lag measure: how old are the dependencies you run compared with the latest releases? Our post on dependency update lag as an exposure metric pairs well with this one. Low noise with high lag means you silenced the tool, not the problem.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings change over time, then think about which of your own counts would show the same trend.
Quick check
What merge rate is good?
There is no universal number. Compare against your own baseline and watch the trend, and investigate when it falls.
Should I count security pull requests in the noise figure?
Report them separately. They are the signal, and mixing them with routine updates hides how fast you handle them.
Safeguard supports continuous monitoring of dependencies against new advisories, builds an SBOM from manifests and lockfiles, and uses reachability analysis to show which flagged packages your code calls. Fix pull requests are off by default, with every category on Manual. A free scan is available.
Sources
Last reviewed: 19 October 2026.
