Track five numbers for automated fix PRs: acceptance rate, edit rate, close reasons, revert rate and time to merge. Together they show whether the tool understands your code and whether your process is safe. Judge them against your own baseline, not someone else's benchmark.
The core metrics
Acceptance rate. Of PRs opened, what share was merged? Low acceptance suggests wrong scope, noisy findings or a bad strategy. Very high acceptance can mean good quality, or rubber stamping. Read it with the next metric.
Edit rate. Of merged PRs, how many needed a human commit first? Edits show where the tool falls short: tests to adjust, call sites to change. A steady drop over time is a good sign.
Close reasons. For closed PRs, the recorded cause, using a fixed list as in when to close a fix PR without merging. The mix tells you what to tune.
Revert rate. Of merged PRs, how many were reverted or followed by a hotfix within, say, two weeks? This is the quality number that matters most. Aim for zero and treat each case as an incident worth a short review.
Time to merge. From PR open to merge, median and a high percentile. If the median is hours and the high percentile is weeks, a few PRs are stuck on ownership or unclear evidence.
Outcome metrics
Process metrics say the PRs are good. Outcome metrics say whether it helps.
- Time to remediate from finding to deployed fix, by severity. Compare against your own pre-automation numbers.
- Open findings with a fix available. A shrinking number means fixes reach production.
- Share of findings fixed by PR versus ticket. Shows how much routine work is automated.
Pitfalls that make numbers lie
Counting auto-closed or superseded PRs as rejections. Separate them.
Measuring acceptance without revert rate. A bot that is merged quickly and reverted often looks good on one chart and bad on the other.
Averaging across tiers. Patch bumps and major upgrades behave differently. Slice by tier and by repository.
Short windows. One quiet week proves little. Review monthly, and after any rule change.
Comparing teams. A team with weak tests will show different numbers than one with strong tests. Use the numbers to help, not to rank.
Making them useful
Pick a small dashboard: the five core metrics, sliced by category and repository. Review it in the same meeting that reviews open critical findings. When a metric crosses a threshold you set, such as two reverts in a month, pause expansion and investigate, as the pilot plan describes.
What not to measure
Number of PRs opened is activity, not value. Lines changed is meaningless. Avoid celebrating volume.
Quick check
What is a good acceptance rate?
There is no universal figure. Compare to your own trend and read it alongside edit rate and revert rate. High acceptance with high reverts is a problem.
Safeguard keeps autonomous remediation off by default, so you gather these numbers under manual approval before widening scope.
Last reviewed: 19 October 2026.
