Severity vs priority is the difference between how broken a bug is and how soon it needs fixing. Severity measures technical damage: does it crash a checkout, corrupt data, or just misalign a button. Priority measures urgency: how soon a fix has to land against everything else competing for the same sprint. A bug can score high on one axis and low on the other, and knowing which team owns which field is what actually settles the argument.
A bug flagged "Critical" didn't make this sprint, or a typo somehow outranked one that did, and now someone in a standup, an interview, or a ticket review wants to know why. That question lands on a QA engineer or SDET, not on the QA lead building a test strategy document, a different job with its own playbook, and not on the team wondering whether their AI-generated suite can be trusted, a separate and harder question. Answering it well takes knowing whose job each word describes, not just the words themselves.
Severity vs priority: two independent axes
Severity is a property of the defect. It describes how much damage the bug does to the system right now, independent of your calendar, your customer list, or your backlog. A crash is high severity whether it affects one account or every account. A misaligned icon is low severity even if the CEO happens to see it during a demo. Severity is something you can observe directly from the defect: what broke, and how far the breakage reaches. Mozilla's Firefox team defines severity as the scope of a bug's effect on the product, and displays it alongside priority rather than instead of it.
Priority is a property of the schedule. It describes how soon a fix needs to land relative to everything else the team could be doing instead: other bugs, planned features, the next release cutoff. Priority is never observable from the defect alone. It needs context severity doesn't carry: who is affected, what it's costing, and what else is competing for the same engineering hour.
The signals meet only after different owners supply different evidence: technical impact for severity and scheduling context for priority.
Cross the two axes and four quadrants fall out. A real, checkable example anchors each one. Real trackers already model these as two separate fields: Bugzilla groups them under one Importance heading, with priority defaulting from P1 through P5 and severity running from blocker down to trivial.
| Priority: high | Priority: low | |
|---|---|---|
| Severity: high | Checkout fails for every customer | Admin report crashes; 3 customers use it |
| Severity: low | Pricing page shows wrong price, live | Typo in a rarely opened tooltip |
High severity and high priority agree with intuition: checkout is down, fix it now, argue about nothing else. Low severity and low priority agree too: a stray tooltip typo waits in the backlog indefinitely, and nobody's wrong for leaving it there. The friction, and the reason this phrase gets searched mid-argument, lives in the other two cells.
High severity, low priority
Take the crash in the admin reporting page: three customers use that flow, once a month, to pull a report before a compliance check. Every attempt fails outright. Judged by severity alone, that's about as bad as a bug gets: nothing renders, no workaround, no partial functionality. Read the ticket cold and it sounds like an emergency.
It isn't one, or at least not yet. Priority asks a different question: does this need to jump the current sprint, and the honest answer is usually no. Three customers hitting a monthly flow is a real defect with a small, predictable blast radius. It belongs in the very next release, triaged and scheduled like any other confirmed bug, not paged to whoever's on call at 11pm.
The failure mode is letting severity's vocabulary set priority's field. A ticket like this usually reads like an incident report: "critical," "blocks a core admin flow," "no workaround," escalate now. Those words sound urgent, and urgency-sounding language pulls a bug out of the backlog and into the current sprint by force of tone rather than force of argument, even though none of those phrases, however accurate, answers the question that actually decides the sprint: what changes if we ship this next release instead of this one? For three customers pulling a monthly report, the honest answer is nothing measurable changes inside that window, and that's how a defect this contained ends up derailing a two-week sprint that was supposed to ship something bigger.
There's a shortcut some teams reach for instead: downgrade the severity label so the low-priority decision looks consistent on paper. Don't. A defect with no workaround that fails outright is high severity by definition, and rewriting it as "minor" corrupts the field for the next person who queries it, say, someone searching for every unrecoverable crash in the admin surface six months from now. Keep severity honest and set priority on its own axis; that separation is the entire reason the two fields exist.
The escalation rule that actually works: name the trigger before the argument starts, not during it. If the affected customer count climbs past a stated threshold, or the flow sits upstream of a compliance deadline the customer has already flagged, or a second, unrelated report of the same crash comes in, the bug graduates into this sprint. Absent one of those, it's scheduled normally: filed with full severity intact, prioritized against the rest of the backlog like everything else waiting its turn.
Low severity, high priority
Flip it. The pricing page shows the wrong number for a plan tier. Nothing crashes. No test fails, because nothing about the page is broken in any way a test suite checks for; the markup renders, the button works, the checkout flow behind it completes normally. Severity, by any reasonable definition, is close to zero.
Priority is not. That number is live, in front of every visitor doing exactly what a pricing page exists for: deciding whether to buy. Every hour it's wrong either undercharges, and revenue leaks out, or overcharges, and a support ticket and a trust problem walks in. The cost of a production bug compounds by the hour here in a way a broken button in a settings panel never does.
This is the case a severity-first triage process misses by design: nothing to reproduce in a test environment, no exception in the logs, no crash to page anyone about, and yet it's the most expensive line item in the whole backlog until someone fixes it.
Automated suites miss this category by construction, not by neglect. A test asserts against a value it was told to expect; if the pricing config was wrong before the assertion was written, the wrong number renders cleanly, the page returns 200, and every check downstream passes. Nothing looks broken in the sense a test checks for, because the defect lives in whether the number matches reality, not in whether the page functions. That's a limit of automated testing in general, ours included, not a gap specific to one tool: a suite verifies behavior against a spec, and has no opinion on whether the spec itself drifted.
The people who actually catch this class of bug are looking at the number for a reason no test has: a salesperson quoting a deal, a support agent fielding a confused customer, the customer mid-checkout. The detection path is a human noticing and saying so, which only works if there's a known channel for that report to travel fast. Write the escalation rule before the typo happens: who gets pinged when a customer-facing number looks wrong, and how fast it needs a fix once flagged.
The escalation rule: anything customer-facing that touches price, billing, or a legal claim gets a priority floor independent of its severity score. Set that floor once, in writing, before the next pricing typo happens, not while someone is trying to decide whether a "cosmetic" bug deserves an interrupt.
How Autonoma informs the severity axis
Every one of the quadrants above starts with someone deciding severity, and that decision is only as good as what actually got observed when the bug happened. This is where a good behavioral test suite earns its place in the triage conversation, and exactly where it stops.
When one of our end-to-end tests fails, what it hands back is a severity signal, not a priority one. It tells you which flow broke, whether the failure stayed on one screen or cascaded downstream, and it tells you the blast radius: does checkout still complete after the failure, or does the whole purchase path die with it. Autonoma's agents read the codebase directly to plan those tests, and our Diffs Agent updates the suite from the code diff on every PR so coverage doesn't quietly rot as the product changes. A failure surfaced that way carries real information about how far the breakage reaches, not a guess based on which file changed.
What it can't tell you is priority, and it isn't supposed to. A failing test doesn't know your release calendar, doesn't know which of the three affected customers is up for renewal next month, and doesn't know the same flow is scheduled for a compliance audit in nine days. Autonoma flags what broke and how far it reaches. Whether that translates into "fix it today" or "fix it next sprint" still runs through the same ownership rule as any other bug: engineering reads the severity, product sets the priority, and no test suite, ours included, gets a vote on the second half of that sentence.
Who owns bug severity and who owns defect priority
The sentence worth lifting out of this whole argument: engineering owns severity because severity is a property of the defect, product owns priority because priority is a property of the schedule, and most severity-vs-priority arguments are actually one function trying to set the other's field.
Engineering can observe severity directly: the stack trace, which service the failure cascades through, whether a workaround exists. Product can observe priority, because priority needs context engineering doesn't carry by default: revenue exposure, contractual deadlines, renewal dates, the roadmap already promised this quarter.
A mis-set field costs in both directions: forcing high priority by inflating severity spends a sprint the calendar didn't require and burns the next "critical" label's credibility, while calling a bug low priority because it sounds cosmetic, without ever assessing severity, lets its real blast radius grow unnoticed.
Unstick the argument by asking which field is actually in dispute, not by arguing louder about the label: how broken it is belongs to engineering, when it gets fixed belongs to product. Most severity-vs-priority arguments dissolve once both sides agree which question they're fighting over. A bug report template that separates the two into owned fields prevents most of this, and risk-based testing already builds that scoring framework.
Every team argues through a few of these before the rule sticks, the bug sitting contested on the board through its own detour in the defect life cycle. A disagreement that recurs on the same class of bug means the escalation rule needs writing down, not re-litigating. Defect escape rate segments how many of these reach production by which stage should have caught them. We built Autonoma to answer the severity half reliably: tests that read your codebase directly and report which flows actually broke, leaving only the decision that was always product's to make.
Frequently Asked Questions
Severity is a property of the defect: how much technical damage it does, independent of schedule or customer count. Priority is a property of the schedule: how soon the fix needs to land relative to everything else competing for the same engineering time. Severity is observable directly from the bug; priority requires context like revenue exposure and release timing that the bug report alone doesn't carry. For example, a crash in an admin report that three customers use once a month is high severity and low priority, while a wrong price on a live pricing page is low severity and high priority.
Yes, and it's one of the two cases that cause the most arguments. A crash in a feature only a handful of customers use is high severity, since nothing works and there's no workaround, but low priority, since the blast radius is small and predictable enough to schedule normally rather than interrupt the current sprint. The usual escalation trigger is a jump in affected customer count or a compliance deadline tied to that flow.
Engineering, in most functional teams, because severity is something you can observe directly from the defect: which stack trace it throws, which service the failure cascades through, whether a workaround exists. It doesn't require knowledge of the release calendar or the customer roster, which is exactly why it belongs with the function that can trace the failure.
Product, in most functional teams, because priority requires context engineering doesn't hold by default: revenue exposure, contractual deadlines, which accounts are up for renewal, and what the roadmap already promised for this quarter. Product is the function with the schedule and the customer relationships in view, so product is positioned to weigh a fix against everything else competing for the same sprint.
Most teams use some version of four tiers: critical or blocker, meaning the system is unusable with no workaround; major or high, meaning a core function is broken but a workaround exists; minor or medium, meaning a non-core function is affected; and low or trivial, meaning the defect is cosmetic. The exact labels vary by tool and team, but the underlying axis is always the same: how much technical damage the defect does, not how soon it needs fixing.
Autonoma can give engineering a clearer severity signal by running planned end-to-end checks on a live preview environment and identifying the user-facing flow that failed. That evidence helps the team assess technical impact before triage. Priority remains a product decision because it depends on release timing, customer commitments, and business context. Used together, Autonoma's test evidence and product context let the right owners make each part of the decision with the information it requires.
