Open almost any bug tracker's reports page and you will find a lot of numbers. Total issues filed. A pie chart of severities. An average resolution time. A bar per assignee.
Almost none of them answer the question a team actually asks on a Monday morning: are we keeping up, or falling behind?
That question has a short answer, and it takes four numbers to give it. This post walks through those four, the popular metrics that quietly mislead, and a five-minute weekly review you can run on top of them. It is also the reasoning behind the pulse header we just put at the top of the BugDump board.
The metrics that look useful and are not
Total bugs ever filed. It only goes up. A number that can only go up tells you how old the project is, not how healthy it is.
Number of bug reports. Reports measure traffic as much as quality. A single broken checkout button can produce forty reports in an afternoon, and that is one bug, not forty. Count reports and a popular release looks like a disaster; count bugs and it looks like a Tuesday.
Bugs by severity, as a pie chart. It describes the backlog without suggesting anything to do about it. Nobody has ever looked at a pie chart and closed a ticket.
Average time to fix. This one does real damage, because it looks rigorous. We will come back to it.
What these have in common is that they are stocks, not flows. They describe a pile. The questions worth asking are about the direction the pile is moving and what is stuck at the bottom of it.
1. Open backlog, and which way it is moving
Start with the simplest number there is: how many bugs are open right now. In BugDump that is every task that has not landed in a closed column.
On its own, the count means little. Twenty-nine open bugs is fine for one team and alarming for another. What matters is the direction, and direction is just arithmetic over a window:
net change = bugs opened − bugs resolved, over the same period
Negative means the backlog is shrinking. Positive means it is growing. Zero with activity means you are exactly keeping pace; zero without activity means nobody touched anything, which is a different situation and deserves a different label.
That is why the pulse header does not just show "29 open". It says backlog down 4 this period, backlog up 6 this period, backlog holding steady, or quiet period, nothing moved. The number gives scale; the sentence gives direction.
A backlog that grows for several periods in a row is rarely a developer productivity problem. It is almost always a triage problem: duplicates are not being merged, won't-fix decisions are not being made, and every report becomes a permanent resident.
2. Fixed vs. opened, compared with the previous period
The second number is how many bugs you resolved in the window, shown against the previous window of the same length.
Comparing with the period immediately before, rather than with an all-time average, matters for two reasons. It cancels out seasonality: a quiet holiday fortnight is compared with the busy fortnight before it, not with your best month ever. And it makes release weeks legible: a release that shipped a fix for a cluster of bugs shows up as a jump, not as noise.
Better still, look at opened and resolved on the same chart. We plot opened bugs above the axis, resolved bugs below it, and the backlog as a line across both. When the two areas mirror each other, you are keeping up. When the top one keeps winning, the line climbs, and you can see exactly which days it started.
3. Median time to fix, not the average
Time to fix is the metric most teams want and most tools get wrong.
The definition is straightforward: for every bug resolved in the window, measure the time from when it was opened to when it was resolved. The question is how you summarize those durations, and the answer should almost never be the mean.
Here is why. Say your team fixes ten bugs this fortnight. Nine are fixed within a day. The tenth is a bug from four months ago that someone finally closed during a cleanup session, 120 days after it was filed.
Mean: (9 × 1 + 120) ÷ 10 = 12.9 days
Median: 1 day
The mean says your team takes two weeks to fix a bug. The median says your team fixes bugs the next day, and it is correct. Worse, the mean punishes cleanup: the week you finally close out ancient tickets is the week your average looks terrible, which teaches everybody to leave ancient tickets alone.
The median is robust to that one outlier, so it tracks what a typical bug experiences. It is what the pulse header shows as Median fix, formatted in minutes, hours, or days depending on scale.
It has one honest weakness: it only counts bugs that were actually fixed. A bug that never gets resolved never enters the calculation, so a team could have a beautiful median while quietly abandoning its hardest problems. Which is exactly why you need the fourth number.
4. The oldest open bug
The median describes the middle. The oldest open bug describes the tail, and the tail is where trust erodes.
Put its age right next to the median: 5 months, with the ID and title underneath. Make it clickable, so looking at it is a single step, not a search.
A five-month-old open bug is almost never a bug nobody could fix. It is a decision nobody made. Looking at it forces one of three honest outcomes:
Fix it, because it turns out to be small.
Schedule it, because it matters and has been orphaned.
Close it deliberately, as won't fix or obsolete, and tell the reporter why.
Any of the three is better than a fourth month of silence. And once the oldest bug is dealt with, the next oldest takes its place, so the number keeps pulling the tail in.
Bonus: where the reports come from
The four numbers above tell you whether you are keeping up. They do not tell you why a week went badly.
For that, break the reports in the same window down by browser, operating system, device type, and page. A regression rarely spreads evenly. When a third of this week's reports come from Safari on iOS, or the top page by report count is a checkout step that shipped on Thursday, you have found your cause before opening a single report.
In BugDump, expanding the pulse header shows exactly this breakdown next to the chart, with the top pages ranked by report count. Clicking a browser, OS, or device chip filters the board to it, so the jump from "something is off with Safari" to the Safari bugs is one click.
This is also where counting reports, rather than bugs, is the right call. Forty reports of one bug are forty data points about who hit it.
Choosing a window
The window changes what the numbers can tell you, so pick it for the question you are asking:
7 days for release weeks, when you want to see the effect of a deploy.
14 days as a sensible default: long enough to smooth daily noise, short enough to react.
30 or 90 days for trend questions and retrospectives.
Be careful with medians over short windows on small projects. The median of three fixes is a fact about three bugs, not about your team.
Define "resolved" honestly
Every one of these metrics depends on what counts as resolved, and this is where dashboards most often lie.
If Ready for QA or Merged counts as resolved, your median fix time measures how fast code gets written, not how fast users stop hitting the bug. If Won't fix does not count, your backlog carries decisions that were already made.
In BugDump, a bug is resolved when it enters a column of the closed type, and moving it back out reopens it. Whatever tool you use, check that its closed states mean what your users would mean by "fixed".
The five-minute weekly review
With those four numbers on one screen, a weekly bug review stops being a meeting and becomes a checklist:
Is the backlog moving down or holding steady? If it grew, look at what came in, not at who is slow.
Did we resolve at least as many as came in, compared with the previous period?
Did the median fix time move? If it jumped, find the one or two bugs that pulled it.
Open the oldest bug. Fix it, schedule it, or close it with a reason. Do not leave it for next week.
Scan where reports came from. Any browser, device, or page carrying far more than its share is a regression until proven otherwise.
That is the whole review. It fits into a standup, it does not need a spreadsheet, and it answers the only question the dashboard was ever supposed to answer.
BugDump adds a bug report button to your site with one script tag, and every report arrives with console logs, network requests, session replay, and environment data attached. The pulse header at the top of each board shows the open backlog and its trend, fixed vs. the previous period, median fix time, and the oldest open bug, updated every minute.