Configuration
Review quality metrics
Precision, dismissals, acknowledgements and repeats — how to tell whether reviews are useful.
More findings isn’t better. The Review quality panel on the Rules page measures whether reviews are useful to your team, using what happened to findings once pull requests closed.
The metrics#
| Metric | How it’s worked out | What good looks like |
|---|---|---|
| Precision | Accepted ÷ (accepted + dismissed), on closed pull requests | High. Below 60% means too many findings your team rejects |
| Dismissed | Share of findings that got a 👎 | Low |
| Acknowledged | Share of findings someone reacted 👀 to or replied on | People are reading the comments |
| Repeats held back | Share of raised findings that were already on the pull request, and so not posted again | Shows how much noise was avoided |
| Findings per review | Average findings on each pull request review | Fewer, correct ones |
| Tokens per review / per finding | AI cost of each review and each finding | Stable or falling |
When developers push back#
The panel also shows what happened after someone disputed a finding:
- Withdrawn: the recheck agreed it wasn’t an issue. A high share means first reviews are raising things they shouldn’t; raise the minimum confidence.
- Upheld: the recheck kept it, with evidence.
- Downgraded: real, but overstated. A high share means severities are too high.
- Fixed after discussion: the conversation led to a fix.
What happened to findings#
Next to the metrics, the Rules page lists the last 90 days of outcomes: accepted, dismissed or ignored, by kind of finding. Use it to spot categories your team never acts on, then add a “Don’t flag” rule or adjust strictness.
Why the numbers start empty
Outcomes are recorded when a pull request closes, because that’s when reactions are read. Precision, dismissals and acknowledgements fill in as reviewed pull requests are merged or closed.