In this guide
Two words get mixed up all the time. Severity is how bad the bug is for the user: what breaks. Priority is how soon you fix it: a decision that also depends on how many people are affected, how easy a workaround is and your release date. A solo developer needs both defined once, so the same bug gets the same rating on Monday and on Friday.
Severity definitions (copy and adapt)
S1 Critical The app crashes, data is lost or corrupted, money is charged wrongly,
or a core flow cannot be completed. No workaround.
S2 Major A core feature is broken or very hard to use, but a workaround exists.
S3 Minor A non-core feature misbehaves, or a core one in an edge case.
S4 Trivial Cosmetic: typo, misalignment, small visual glitch.
Reach (how many are affected)
Many Most users or every user on a common device / OS / flow
Some A clearly defined group (one device family, one language, one account type)
Few Rare conditions or one reported case
The matrix
Priority from severity (rows) and reach (columns):
| Many | Some | Few | |
|---|---|---|---|
| S1 Critical | P0: fix now, stop release | P0: fix now | P1: fix before release |
| S2 Major | P1: fix before release | P1: fix before release | P2: next release |
| S3 Minor | P2: next release | P2 or P3 | P3: backlog |
| S4 Trivial | P3: backlog | P3: backlog | P3: backlog, or close |
Priority meanings: P0 drop everything. P1 must be fixed before this release goes out. P2 plan for the next release. P3 backlog, fix when nearby.
Template for rating a bug (copy and paste)
BUG: <title>
Severity: S<1-4> Reach: <many / some / few> Priority: P<0-3>
Workaround: <yes: describe / no>
Why this rating: <one sentence>
Decision: <fix now / before release / next release / backlog> Date: <date>
Example (illustrative)
BUG: App crashes when saving with an empty title
Severity: S1 Reach: Some (only users who skip the title field) Priority: P0
Workaround: Enter a title
Why this rating: Crash with data loss on the main save action; a workaround does not remove the crash.
Decision: fix now Date: 2026-11-05
How to adapt it
- Override with a reason. Rules are for the 90 percent; write down why you broke one.
- Raise the priority for risks beyond the matrix: security or privacy problems, payment errors and anything that could breach store rules should not wait. Check the current policies for the last.
- Use real data when you have it. Crash reports show reach; see how to prioritize crash reports and how to prioritize app feedback.
- Keep four levels at most. More levels mean more arguing and no better decisions.
- Tell testers what you mean so their severity guesses match yours; the final call stays with you.
Related
- Hub: Mobile app testing checklist hub
- Known issues list for testers
- Release go / no-go checklist
Start free to gather bug reports in a structured way, then rate them with this matrix.