No. Releasing with known defects is not automatically bad testing, bad management or the beginning of the apocalypse. Almost every serious product ships with known defects at some point.
The stupid bit is pretending that “known defect” tells you anything useful on its own. If you are staring at a defect list and wondering whether somebody made a reckless call, we can review it with you. But first look at what those defects actually meant.
A defect is not a unit of risk
Ten cosmetic issues are not necessarily more important than one defect that loses a customer’s data. A severity label helps, but even severity becomes theatre when teams spend more time arguing over whether something is a Sev 2 or Sev 3 than discussing what happens to the user.
The useful questions are practical. Who is affected? How often? What happens when it occurs? Can the user recover? Can you detect it? Is there a workaround? Can it cause financial, legal, security or reputational damage? How quickly can you fix it after release?
Good release decisions are trade-offs
Imagine a low-volume internal system with a formatting defect and a workaround that takes ten seconds. Delaying the whole release for that may be ridiculous. Now imagine an app that occasionally assigns one customer’s data to another customer’s account. Same phrase — “known defect” — completely different decision. That is also the basis for deciding whether the number of bugs really justifies a delay next time.
This is why blanket rules such as “no Severity 2 defects at go-live” often become nonsense. Teams eventually game the labels to fit the gate instead of making a better decision. Congratulations: the defect is now officially less severe and still exactly as broken.
What would make it a bad decision?
It becomes a bad decision when the consequence was not understood, when the issue was hidden or softened, when nobody actually accepted the risk, or when the mitigation existed only in a slide deck. It is also a bad sign if the same type of known defect keeps getting released because fixing the underlying cause is less attractive than having another defect meeting.
If you knowingly released something risky because the benefit outweighed the downside, and you had monitoring, support and a credible recovery plan, that may have been perfectly sensible. Software delivery is not a competition to achieve moral purity through zero open Jira tickets.
Look at the mitigation, not just the defect
A known defect can be acceptable because of what surrounds it. Maybe monitoring catches it immediately. Maybe support can reverse the transaction. Maybe the affected feature is behind a flag and can be disabled without taking the service down. Those things materially change the risk.
But write down what the mitigation actually is. ‘Operations will monitor’ is not a mitigation if Operations has no alert, no runbook and no idea the defect exists. A mitigation that depends on everybody remembering a meeting is optimism with admin.
If you want us to look at the defects, release rationale and whether the risk was genuinely understood, get onto us. We can tell you whether the decision looks proportionate or whether somebody simply renamed the problem until it fitted through the gate.