What Do Production Bugs Actually Cost You? We Built a Calculator to Find Out
NorthQA TeamAsk a development team whether bugs reaching production are expensive and everyone says yes. Ask what that costs per year and the room goes quiet.
It is not that nobody cares. It is that the cost is spread across so many people and so many interruptions that it never lands in one place where anyone can see it. There is no line item called "defects we shipped by accident."
So we built a calculator that puts a number on it.
Five inputs you already know. No signup, no gate, and every constant in the model is printed on the page.
The fix is the smallest part of the bill
When we ask a team how long a production bug takes to deal with, we almost always get one number: how long it takes an engineer to write the fix.
That number is real, and it is also the least expensive part of what just happened.
A defect a developer catches while the code is still fresh is a small correction. The same defect found by a user is an incident. Someone has to triage it. Someone has to reproduce it, which is often harder than fixing it. Someone has to verify the fix. Someone has to ship an unplanned release, outside the release process you spent years making safe.
And every one of those people was doing something else first.
That last part is the cost teams almost never count. An engineer pulled off planned work does not resume at full speed the moment the incident closes. The ramp back in is real, it happens on every single defect, and it never appears on any ticket.
What the calculator actually counts
The model splits the annual cost into three parts, because seeing where the money goes is more useful than seeing a total.
Writing the fix. Your number, straight from the input. This is the part teams already estimate.
Triage, re-testing and the emergency release. Time spent by people who are not writing the fix. We model this at 2.5 hours per defect.
The interrupt itself. Planned work displaced and picked back up, modelled at 1.5 hours per defect.
At the calculator's default inputs, a team of 12 shipping four releases a month with 18 defects reaching production is looking at $162,000 a year. Only about 60 percent of that is the fix. The rest is everything the fix drags along with it.
The number that tends to land hardest is not the annual total, though. It is two others the calculator shows alongside it:
- How many defects escape to users on every release you ship
- What share of your team's annual capacity unplanned defect work quietly consumes
Most teams have never seen either figure written down.
Why we published every constant
Cost-of-quality calculators have a bad reputation, and they earn it. Plenty of them work backwards from a number the vendor wants you to see, resting on an industry study that either does not exist or does not say what the footnote claims. The most-quoted defect cost figures in our field trace back to sources almost nobody has actually read, and the multipliers get rounder every time they are repeated.
We did not want to add to that pile. So the rule we set for this tool was simple:
Every figure the calculator shows is a number you entered, multiplied by a constant printed on the same page.
Open the "How this is calculated" section and you get the whole model: the arithmetic, all of the constants, and what each one is for. If you think 2.5 hours of coordination per defect is too high for your team, you can see exactly which line to argue with and exactly how much it moves the total.
A number you can audit and disagree with is worth more than a number you have to take on faith.
What "recoverable" means, and what it does not
The calculator also estimates what moving detection earlier would recover, driven by a slider: what share of these defects would a disciplined pre-release process have caught?
There is an obvious way to inflate that figure, which is to treat every prevented defect as pure savings. That would be wrong. Catching a bug before release is not free. Somebody still writes the test, still investigates the failure, still fixes it.
So the recoverable figure is a difference, not the whole production cost. We model a pre-release defect at 18 percent of what the same defect costs in production, and the tool reports the gap between the two. It is a smaller and more defensible number than the one we could have shown.
What it deliberately leaves out
The calculator is conservative on purpose. It does not count:
- Customers who churned after hitting the bug
- Support and success time spent fielding the reports
- SLA credits or contractual penalties
- Reputational cost and lost deals
All of these are real, and some of them dwarf the engineering cost. None of them can be honestly estimated from five inputs, so we left them out rather than guess.
Whatever number the calculator gives you is a floor, not a ceiling.
Try it on your own numbers
If your defect count is genuinely low and your releases are clean, the tool will tell you that, and that is a fine outcome. Not every team has a quality problem worth paying to fix.
But if the figure is larger than you expected, that gap is the useful part. It is the difference between "bugs are expensive" as a thing everyone nods along to, and a number you can take into a planning conversation.
You can share the result, too. The tool encodes your inputs in the URL, so sending the link to a colleague shows them your scenario rather than the defaults.
If you want to talk through what comes out of it, book a 30-minute QA audit. We will go through your actual release process, not a spreadsheet.
Need Help with Quality Assurance?
At NorthQA, we provide comprehensive software quality assurance services to ensure your applications are robust, reliable, and bug-free.