The Bug Reviews inbox carries an analytics tab. It reports totals against the previous period, resolution and rejection rates, average/median/p90 time to resolve, the current open backlog with its oldest and average age, and the share of resolved tickets flagged recurring by fingerprint. Filters narrow by org, platform area or bug type.
Also called: support metrics · how fast do they fix things · issue trends · recurring bugs
- 1Everything is computed server-side so the browser never pulls the full report corpus to count it
- 2The time bucket — day, week or month — is chosen from the length of the requested range
- 3Every average ships with its sample size, and the UI states which it is
- 4Rates are defined explicitly: resolved over triaged is the real-issue rate; rejected over triaged is the noise rate
Support quality is easy to claim and hard to evidence, and a single average hides the thing that matters: a two-day fix time over three tickets is not the same claim as two days over three hundred. Everything filed is measured — how much of it was real, how fast it closed, what is still open and how old that pile has become, and which problems keep coming back. Every average is shown with the number of tickets behind it, so a flattering number cannot be assembled out of a handful of cases.
- Support performance is claimed rather than measured
- Repeat problems are treated as new every time
- A backlog can look fine while quietly aging
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →