Bug Severity vs Priority Matrix
Pick the impact, reach, and workaround to get a suggested severity level and P0–P4 priority, then copy it straight into the bug ticket.
Open source on GitHubClassify the bug
A specific segment, setting, or device.
Suggested classification
Severity
S3
Major
Priority
P2
Major impact affecting some users gives a base priority of P2; no workaround is available. Schedule in an upcoming sprint.
| Impact / reach | All | Most | Some | Few |
|---|---|---|---|---|
| Blocker | P0 | P0 | P1 | P2 |
| Critical | P0 | P1 | P1 | P2 |
| Major | P1 | P2 | P2 | P3 |
| Minor | P2 | P3 | P3 | P4 |
| Trivial | P3 | P4 | P4 | P4 |
Ticket snippet
Severity: S3 - Major Priority: P2 - Medium Reach: Some users Workaround: No Rationale: Major impact affecting some users gives a base priority of P2; no workaround is available.
Severity vs priority. Impact is not the same as urgency.
| Severity | Priority | |
|---|---|---|
| Question it answers | How bad is the impact on the product? | How soon should we fix it? |
| Set by | Usually QA or the reporter | Usually the product owner or triage lead |
| Based on | Technical and user impact | Business value, reach, deadlines, and capacity |
| Changes over time | Rarely; the impact stays the same | Often, as releases and priorities shift |
| High severity, low priority | Crash in a feature almost no one uses | Fix later; the reach is tiny |
| Low severity, high priority | Typo in the company name on the homepage | Fix now; it is highly visible |
Bug severity levels. Definitions and examples for each level.
| Severity | Definition | Example |
|---|---|---|
| S1 · Blocker | The product or a core flow can’t be used at all: crash on launch, login down, checkout fails for everyone, data loss, or a security hole. | App crashes on launch; payments fail for all users |
| S2 · Critical | A major feature is broken or produces wrong results, with no reasonable way around it for most people. | Search returns wrong results; export produces a corrupt file |
| S3 · Major | A feature works incorrectly or partially; users can get their task done, but with real friction. | Filter resets after each page load; slow report generation |
| S4 · Minor | Small functional issue or confusing behavior that rarely gets in the way. | Tooltip shows on the wrong element; sort order inconsistent |
| S5 · Trivial | Cosmetic: typo, misalignment, or a color off-brand, with no effect on function. | Typo in the footer; icon misaligned by a few pixels |
Priority levels P0 to P4. What each priority means for the team.
| Priority | Typical response |
|---|---|
| P0 · Urgent | Drop other work; fix or roll back now, hotfix if needed. |
| P1 · High | Fix in the current sprint or before the next release. |
| P2 · Medium | Schedule in an upcoming sprint. |
| P3 · Low | Fix when there is capacity; group with related work. |
| P4 · Backlog | Nice to fix; revisit during backlog grooming. |
The bug life cycle. From report to closed, and the detours in between.
| Stage | What happens | Owner |
|---|---|---|
| New | The bug is reported with steps, environment, and evidence. | Reporter (QA, support, or user) |
| Assigned | Triage confirms it, sets severity and priority, and assigns an owner. | Triage lead or product owner |
| In progress | The developer reproduces the bug and works on a fix. | Developer |
| Fixed | The fix is merged and deployed to a test environment. | Developer |
| In verification | QA retests with the original steps and checks for regressions. | QA |
| Closed | The fix is verified and the bug is done. | QA |
| Reopened | Verification failed or the bug came back; it returns to the developer. | QA |
| Deferred | Valid, but postponed to a later release. | Product owner |
| Rejected | Not a bug, a duplicate, or can’t be reproduced. | Triage lead |
More free tools. Free, open source, no sign-up. See all tools · Source on GitHub
Frequently asked questions
What is the difference between severity and priority?
Severity describes how much a bug hurts the product or its users. Priority describes how soon the team should fix it. They usually move together, but not always: a crash in a rarely used admin screen can be high severity and low priority, while a typo in your brand name on the homepage is low severity and high priority.
What are the bug severity levels?
A common scale has five levels: Blocker (S1), Critical (S2), Major (S3), Minor (S4), and Trivial (S5). Some teams use four, merging Blocker and Critical. What matters is that everyone on the team uses the same definitions.
What do P0, P1, P2, P3, and P4 mean?
They are priority levels. P0 means drop everything and fix now, P1 means fix in the current sprint or before release, P2 means schedule it soon, P3 means fix when there is capacity, and P4 is backlog. Map them to your own response targets.
How does this matrix decide priority?
It combines impact (rows) with how many users are affected (columns) to get a base priority, then lowers it one step if a reasonable workaround exists. Treat the result as a starting point for triage; deadlines, customer commitments, and security concerns can justify moving it.
What are the stages of the bug life cycle?
A typical bug life cycle is New, Assigned, In progress, Fixed, In verification, and Closed. Along the way a bug can also be Reopened when the fix fails verification, Deferred to a later release, or Rejected as a duplicate, not a bug, or not reproducible.