Estimated Bug Density Metric

Last updated: October 27, 2026

Estimated Bug Density (90d) shows how often merged pull requests introduce bugs that someone later fixes, relative to the size-weighted amount of work merged. Lower values mean fewer escaped bugs per unit of work.

Why it matters

Speed only helps if quality holds. Bug density tells you whether faster delivery, AI-assisted work included, is shipping more bugs. Teams use the list of detected defects to find common themes in escaped bugs and work backward: could a lint rule, a review guardrail, or a test have caught this earlier?

How it works

1. Find bug-fix PRs. Span classifies every pull request with an LLM, using the diff, a linked ticket marked as a bug, and bug labels on the PR. Refactors, feature work, test-only changes, dependency updates, and long-lived bugs are filtered out. Only PRs classified as bug fixes with high or medium confidence go to the next step.

2. Find the PR that caused the bug. For each bug fix, an AI agent works in a sandboxed copy of the repository and goes back through the git history (blame, logs, and diffs) to find the PR that introduced the bug. A second pass verifies that the fix addresses what that PR introduced. Only verified root causes count.

3. Count defects. A defect counts against the PR that introduced it when its fix PR was opened within 90 days of that PR merging.

4. Divide by weighted PRs.

Est. Bug Density (90d) = escaped defects ÷ weighted PRs

  • Escaped defects: all verified defects traced to a PR within 90 days of its merge, whether the code was AI-written or human-written.

  • Weighted PRs: every PR carries a weight that combines its complexity and size, so a team shipping many small PRs doesn't look safer than one shipping fewer large ones. See Weighted PRs/Week.

  • Filters: only PRs from development contributors count, and PRs merged on out-of-office days are left out.

5. Check coverage. Span shows a value only when the selected period has at least 10 merged PRs and at least 70% of them have been fully evaluated. A PR is fully evaluated when its 90-day window has closed and Span has root-caused nearly all the bug fixes in that window. Otherwise the metric shows insufficient data.

Where you see it:

  • Insights → Productivity → Quality → Bug density: a trend chart and a breakdown table, with a link to the detected defects list.

  • AI Effectiveness → AI insights → Comparison: the Quality card compares bug density between PRs with more and less AI-written code.

  • Detected defects (90d): each defect with a Bug Summary, the PR that introduced it, its Merge Date and Author, Fixed In PR, Fixed By, and the AI Code Ratio range of the PR that introduced the bug (from Agent Traces, where your organization collects them).

Setup

  • Span turns bug density on for your organization on request.

  • Your source control must be GitHub or GitLab. If your organization also connects GitHub Enterprise Server, Azure DevOps, or Bitbucket, bug density is unavailable.

  • The Est Bug PR Density setting in Settings → Metrics must stay on. It is on by default.

Things to know

  • The newest 90 days are blank by design. A PR merged 60 days ago can still produce bugs for another 30 days, so counting it now would make quality look better than it is. If your date range overlaps the last 90 days, the chart shows "The selected period includes PRs that are still in this metric's observation window." Click Jump before window to move the same-length range so it ends just before the window.

  • Slow defect discovery is undercounted. Bugs fixed more than 90 days after the PR merged don't count, so teams with infrequent releases or delayed monitoring may see lower-than-actual bug density.

  • Only bugs fixed through a PR count. Bugs fixed outside a pull request, or never fixed, don't appear.

  • No per-person view. You can break bug density down by team, repository, and other groupings, but not by person.

  • A spike needs context. Because the metric is weighted by complexity and size, a spike can mean more defective code or a period of unusually complex, high-risk work. Use the detected defects list to check.

  • Worked example: a team merged PRs with a total weight of 100 in the selected period, and Span traced 5 verified bugs back to them within 90 days of their merges. Bug density is 5 ÷ 100 = 5%. If you pick "Last 3 months" today, the range overlaps the observation window; Jump before window shows the 3 months that ended 90 days ago.

Related articles

Comparison Report

Weighted PRs/Week

PR Revert Rate

Change Failure Rate Report

Need help?

Contact your Span account team or reach out to support@span.app.