Severity vs Priority

Severity in depth

Severity describes what the bug does when it happens. It’s mostly a technical, factual judgment: does the app crash, lose data, take money incorrectly, or just look a bit off?

A typical severity scale

Severity	What it means	Mobile / web example
Blocker	Stops a key flow or further testing completely; no workaround. Release can’t go out	The app crashes on launch after the update; the website shows a blank page
Critical	Crash, data loss, security or privacy problem, or money handled wrongly	Workout history disappears; customers see other people’s orders; a discount is applied twice
Major	A main feature is broken or gives wrong results, but there’s a workaround	Apple Pay fails but card payment works; search ignores the city filter
Minor	A small feature misbehaves or is awkward; the user can carry on	Sorting puts sale items last; the “Clear” button needs two taps
Trivial	Cosmetic only: typos, spacing, colors, alignment	A label is 2 px off-center; a tooltip has a typo

How to rate severity: five questions

Priority in depth

Priority is about order. A team can only fix so many bugs per sprint, so someone has to decide what comes first. That decision weighs severity against everything else the business cares about.

Priority	In practice	Example
P1 / Highest	Drop other work. In production, often a hotfix the same day	Checkout crashes for all Android users
P2 / High	Must be fixed before the next release or within this sprintSprintA short, fixed period (often two weeks) in which a team builds and tests a set of work.Open in glossary →	Sorting by price shows sale items last, every day costing some sales
P3 / Medium	Planned for an upcoming sprint	Reorder button broken on iPad landscape, workaround exists
P4 / Low	Backlog; fixed when convenient, or eventually closed as Won’t fix	A misaligned icon in Settings

Priority also changes over time. A P3 bug becomes P1 when the marketing team announces that feature tomorrow, and a P1 drops to P3 when the launch is postponed. Severity changes only when you learn new facts about the impact.

Who sets which

	Severity	Priority
Question	How bad is it?	How soon do we fix it?
Based on	Technical impact on the user and product	Business needs: users, money, dates, risk
Usually proposed by	Tester (who saw it happen)	Product owner, lead or triage group
Changes when	New facts about impact appear	The context changes (dates, customers, other work)

Why this split? The tester is the person who saw the bug, knows how to reproduce it and what it breaks, so they’re best placed to judge impact. The product owner sees the whole picture: the roadmap, the campaign next week, the big customer who complained, the five other bugs competing for the same developer.

The four combinations in depth

• High severity, high priority. The easy one. The app crashes when tapping “Place order” for every Android user. Money is lost every minute and there’s no workaround. Everyone drops what they’re doing; if it’s in production, a hotfix goes out.
• High severity, low priority. The banking app crashes when exporting transactions as CSV, but only on Android 9 (2% of installs), the feature is used by 0.3% of users, and the website export works. The impact for that user is bad, but reach is tiny and there’s a workaround. It gets fixed, just not tonight.
• Low severity, high priority. The brand name “FitPulse” is misspelled “FitPluse” in the homepage banner the day before a launch campaign. Nothing is broken, but every new visitor sees it and it makes the company look careless. It’s a five-minute fix with a big brand payoff.
• Low severity, low priority. An icon in Settings sits 3 px lower than its neighbors. Log it so it’s not forgotten, and fix it when someone is in that code anyway.

What pushes priority up or down

Factor	Pushes priority up	Pushes priority down
Users affected	Everyone, or a key group (all iOS users, all new sign-ups)	One rare device, a beta OS, an internal tool
Money	Payments fail, wrong prices, lost orders	No effect on revenue
Legal, security, privacy	Personal data exposed, accessibility law, missing legal pages	None involved
Dates	Release tomorrow, campaign launch, app store feature	Launch postponed, feature behind a flag
Workaround	None, or users can’t find it	Easy and obvious
Visibility and brand	First screen, app store screenshots, press	Deep in a rarely used screen
Regression	It worked in the last release (users notice what they lose)	Long-standing, nobody complained

Mobile vs web: why fixing speed matters

The same bug can get a different priority depending on how quickly a fix can reach users.

Mobile appsWebsites

• A fix needs a new build, a store review (often quick, but never instant) and then users have to update. Many don’t for weeks.
• That means bugs found before a release are worth fixing early: once the build is out, it stays on phones.
• Teams protect themselves with staged rollouts (releasing to a small percentage first), remote feature flags and, in emergencies, a forced updateForced updateA blocking 'Update required' screen shown when the installed version is older than a minimum set on the server.Open in glossary →.
• Bugs on old OS versions or rare devices matter more or less depending on your fragmentationFragmentationThe huge variety of device models, screen sizes and OS versions an app must support.Open in glossary → data: check the analytics before you argue. See Device Fragmentation.

• A fix can often be deployed in minutes, and every user gets it on their next page load (if caching is handled correctly).
• That can make the team more relaxed about shipping a low-severity bug and fixing it the next day.
• But web bugs can be public and instant: a broken checkout or a typo on the homepage is seen by every visitor right away, and search engines and screenshots keep it around.
• Browser share matters: a Safari-only bug can affect most of your mobile web visitors. See Cross-Browser Testing.

Arguing for a severity, with evidence

Sometimes you’ll believe a bug is more serious than the team thinks. That’s a good instinct, but volume doesn’t convince anyone. Facts do.

Common mistakes

• Everything is Critical. If every bug is critical, none is. Save the top level for crashes, data loss, security, money and blocked key flows.
• Rating with emotion. A bug that annoyed you for an hour isn’t automatically severe. Ask the five questions.
• Mixing up rare and minor. A rare crash is still a crash. Keep severity about impact and put the frequency in the report.
• Setting priority alone. Unless your team says so, priority is the product owner’s call.
• Never revisiting. When the context changes (a launch date moves, a big customer complains), priorities should change too. Speak up when you notice.

There’s also a classic interview question on this topic: see What is the difference between severity and priority?