Severity is how badly a bug breaks the product. Priority is how soon you are going to fix it. Severity comes from what the bug does, and priority comes from what the bug costs the business right now.

The two usually move together, which is why people mix them up. The useful cases are the ones where they do not, such as a typo on the homepage the day before launch: trivial severity, top priority.

Severity and priority at a glance

	Severity	Priority
The question it answers	How much damage does this do?	When should we fix it?
Based on	Technical and functional impact	Deadlines, revenue, reputation, budget
Usually set by	Tester or developer	Project lead or product owner
Changes over time?	Rarely, unless new facts appear	Often, as deadlines and plans change

Bugzilla's documentation draws the same line: priority ranks bugs for the order of work and is normally set by the assignee or someone with authority over their time, while severity describes how serious the problem is, from a blocker down to a minor cosmetic issue.

The severity vs priority matrix, with website examples

All four examples are on a fictional online shop.

	High priority	Low priority
High severity	Card payments fail at checkout for every customer	The admin CSV export crashes, but one person uses it once a quarter
Low severity	The company name is misspelt in the homepage headline the day before launch	A footer icon sits two pixels out of line at one tablet width

High severity, high priority. Nothing can be bought and money is being lost every minute. Everyone stops and fixes this.

High severity, low priority. The feature is completely broken, so the severity is high. But it affects one person, and the data can be pulled from the database by hand until a quieter week. Log it honestly and schedule it.

Low severity, high priority. Nothing is broken at all. It still goes first, because the client's name is wrong on the most visible page of the site and the launch is tomorrow. Legal wording and pricing errors often land here too.

Low severity, low priority. Nobody is blocked and hardly anyone will notice. Fix it next time someone is working in that template, or close it.

A ready-to-use severity scale

Copy this into your project documentation or your tracker. Four levels are enough, because more than that and people start debating the difference between levels.

Level	Name	Definition	Website examples
S1	Critical	The site or a main revenue path is unavailable, data is lost or security is compromised, with no workaround	Site down, checkout fails, enquiries silently lost, customer data exposed
S2	Major	A key feature is broken or wrong for many users, and any workaround is hard to find	Search returns nothing, the mobile menu will not open, discounts apply the wrong price
S3	Minor	A feature partly fails, or there is a workaround people can use	Filters reset on the back button, a form error message is wrong, layout breaks at one screen width
S4	Trivial	Cosmetic or wording only, with no effect on use	Typo in the footer, slight misalignment, wrong hover colour

A matching priority scale

Level	Name	Meaning	Plan
P1	Urgent	Other work stops	Fix and deploy as soon as it is ready
P2	High	The next thing to pick up	This release
P3	Normal	Planned work	A coming release
P4	Low	Fix if convenient	Backlog, reviewed each release

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Turning severity into a starting priority

Severity alone should not set priority, but it gives triage a sensible first guess. Start here and adjust for deadlines:

	Hits many users or revenue now	Hits few users, or has a workaround
S1 Critical	P1	P1 or P2
S2 Major	P1 or P2	P2 or P3
S3 Minor	P2 or P3	P3 or P4
S4 Trivial	P3, or P1 if it is highly visible before a launch	P4

One rule keeps this honest: anyone who raises a priority above its starting point writes one line saying why.

Worked example: triaging three bugs

Here is how that plays out on the same fictional shop, one week before launch.

The basket total ignores delivery on orders over £50. Customers are undercharged. Severity S1, because the shop is taking the wrong money. Many users, so priority P1.
Product images load slowly on the sale page. It works, but it is sluggish. Severity S3. There is no effect on checkout, so P3, and it gets revisited if the sale page becomes the campaign landing page.
The privacy policy link in the footer points to the old site. Severity S4, as one link is wrong and nothing else is affected. It is a legal page and launch is a week away, so it moves up to P2.

A good triage takes a couple of minutes per bug. If it takes longer, the report is probably missing detail, and a consistent bug report template fixes that upstream.

Who decides severity and who decides priority

Decision	Who makes it	Why them
Suggests severity	The reporter	They saw it happen
Confirms severity	Tester or developer	They know how far the fault reaches
Sets priority	Project lead or product owner	They know the deadlines and budget
Sets priority on agency work	The client lead, advised by the PM	It is their budget and their launch
Breaks a tie	One named person	Otherwise the loudest voice wins

Clients should not be asked to pick a severity level. Ask them how much the bug is getting in their way, then translate the answer at triage. The client-friendly template in our bug report template post does exactly that.

A short triage slot beats a long meeting. During a test round, a daily fifteen minutes with the PM and one developer is usually enough to clear the list. Agree what happens to each outcome using the software bug life cycle.

Severity and priority in Jira

Jira ships with a priority field and default values of Highest, High, Medium, Low and Lowest. It has no severity field out of the box. Atlassian's older documentation explains that the field was removed because it confused business users, and suggests a select-list custom field if you want it back.

If your team only needs one, keep priority and record severity as a label on the most serious bugs. If you do client work, keep both, because the disagreement between them is often the useful part of the conversation.

Common mistakes

Everything is Critical. If more than a small share of your bugs are S1, the scale has stopped meaning anything. Check them against the definition.
Severity set by frustration. Severity describes the fault and not how annoying it was to find.
Priority never revisited. A P3 in week one can be a P1 in launch week. Re-rank at every release.
Treating severity as a queue. Working strictly from S1 downwards will leave a cheap, high-value P1 waiting behind a slow S2.
No written definitions. Without a scale that everyone can read, a "major" bug is whatever the last person thought it was.

A visual bug report with a screenshot and the exact element pinned makes severity much quicker to confirm, because the reviewer can see the fault before they read about it.

Revolutionise your QA processes

FAQ

Can a bug be low severity and high priority?

Yes, and these are the bugs that the distinction exists for. A misspelt company name on the homepage breaks nothing but needs fixing before anything else.

Can a bug be high severity and low priority?

Yes. A crash in a rarely used admin feature is a serious fault, but if it affects one person and has a workaround, it can wait.

Who should set bug severity?

The reporter can suggest it, but a tester or developer should confirm it, because they can judge how far the fault reaches. Priority belongs to whoever owns the deadlines and the budget.

Do I need both severity and priority?

Small teams can get by with priority alone. Keep both when non-technical stakeholders are involved, because a separate severity stops the technical impact being lost when business priorities change.

What is the difference between a blocker and a critical bug?

The terms vary between tools. Bugzilla's scale starts at blocker, meaning the application is unusable. In the scale above, S1 Critical covers the same ground, so pick one word and define it in writing.