Why Bugs/Issues Reported matters
A rise can mean worsening quality, broader usage, better reporting access, or duplicate reports from one incident. A fall can reflect improvement or lower reporting and usage.
- Business question
- How many product issue reports are users submitting?
- Teams that use it
- Product, engineering, quality assurance, support, and operations teams.
- Decisions it supports
- Triage staffing, release monitoring, root-cause investigation, quality priorities, and customer communication.
Bugs/Issues Reported formula
Count of Bug Reports
Formula components
- Bug report
- A qualifying user-submitted record classified under the agreed issue taxonomy.
- Report date
- The timestamp used to assign the report to a reporting period.
- Duplicate rule
- Whether repeated reports of the same underlying defect remain separate or are deduplicated.
- Scope
- Included channels, products, versions, and customer populations.
How to calculate Bugs/Issues Reported
- Define qualifying report types, sources, and the reporting period.
- Remove spam, tests, and records outside the product scope.
- Apply the documented duplicate rule and classify reports consistently.
- Count qualifying report records; separately track confirmed unique defects and severity.
Bugs/Issues Reported example
In the week after a release, support and in-product channels receive 213 issue records. Triage removes 17 spam or test records and 12 records outside the product scope.
- Raw issue records = 213.
- Excluded records = 17 + 12 = 29.
- Qualifying bug reports = 213 − 29 = 184.
Bugs/Issues Reported is 184 for the week.
Users submitted 184 qualifying issue reports. This is not the same as 184 unique confirmed defects because several users may report one defect.
How to interpret the result
Pair report count with active users, severity, affected accounts, confirmed defects, version, and duplicate clusters. A widely reported critical defect deserves different action from many minor questions.
Report volume depends on user base, release cadence, reporting friction, support channels, and classification. It is not a standalone quality benchmark.
Common mistakes and limitations
- Equating reports with defects
- Multiple reports can point to one bug, and some reports are usage questions.
- Ignoring exposure
- More users or sessions can create more reports even at a stable issue rate.
- Inconsistent classification
- Support teams may label the same issue differently over time.
- Treating all severity equally
- Count alone does not show business or customer impact.