Bug severity vs priority is a question that comes back at every review of customer reports. Severity describes the technical impact: what stopped working and whether there is a workaround. Priority answers a different question: when the team will deal with it, given customers, deadlines and everything else on the list. Mix them in one field and every discussion about order becomes an argument about how much it hurts.
This guide is for small teams where one person is often tester, support agent and product owner. You will get a severity scale defined by impact, the evidence that genuinely raises priority, and the moment a report gets an owner. The order of replies in the support inbox is a separate topic; here we cover the order of product fixes.
Severity describes impact, priority describes timing
You rate severity by looking at the bug itself: which feature is affected, whether data is at risk, whether a workaround exists. It rarely changes unless your knowledge of the bug does. Priority depends on the surroundings: how many people hit the bug, whether it blocks sales, whether a campaign launches next week. The same bug can keep a stable severity while its priority rises or falls from week to week.
The Bugzilla documentation keeps the fields apart: severity states how serious the problem is (from an unusable application to a cosmetic issue), while priority is set by the assignee or someone who directs the team's time. It describes one tool's convention, not a standard every team must follow.
A practical rule: severity is set by the person who reproduced the bug and understands its impact, priority by the person who decides the work plan. In a small company that may be one person, but record both ratings separately. A month later you can see whether a bug waited because it was minor or because someone knowingly postponed it.
A severity scale defined by impact, not emotion
Severity levels only work when everyone reads them the same way. Define them by the impact a user sees, not by adjectives. The scale below has four levels and two fictional examples: an online tea shop and a physiotherapy practice that takes bookings online.
Scroll the table sideways to see all columns.
| Level | Technical impact | Fictional shop | Fictional practice |
|---|---|---|---|
| S1 critical | A core function fails with no workaround, or data is lost or exposed | Checkout fails for every payment method | The form saves no bookings at all |
| S2 major | A core function works partly or only with a workaround | A discount code only applies after refreshing the cart | The slot is saved but no confirmation email goes out |
| S3 moderate | A secondary function misbehaves, the goal is still reachable | Sorting by price shows products in the wrong order | The location filter shows an extra entry |
| S4 minor | Cosmetic: text, alignment, a typo | A typo in the site footer | A misaligned icon in the price list |
Base severity on what has been verified, not on the customer's first message. Once reproduced, "nothing works" is often S2 with a simple workaround. Set the rating only after completing the bug report handoff template, when you know the steps, the environment and the actual result.
Four combinations of severity and priority
The cases where the two ratings diverge teach the most. A serious bug in a rarely used feature can wait, while a small mistake on the home page may be more urgent than a crash in the admin area. The table shows fictional examples and a decision for each.
Scroll the table sideways to see all columns.
| Combination | Fictional example | Decision |
|---|---|---|
| High severity, high priority | Checkout fails on the day a campaign starts | Owner right away, current work waits |
| High severity, low priority | A legacy export format freezes the admin panel; one person uses it once a quarter and knows a workaround | Backlog with the workaround described and a review date |
| Low severity, high priority | A home page banner shows the wrong end date for a promotion | Quick fix, because it is a promise to customers |
| Low severity, low priority | A typo on a rarely visited page | Backlog, fixed alongside another change |
An article by Sauce Labs describes severity as a bug's technical impact and priority as the order of fixing based on user and business impact, with similar four combinations. It also suggests a sample 1 to 10 scale with broad descriptions for each band. It is one vendor's proposal, not a standard.
What raises priority: conversations, recordings and goal impact
Priority without evidence quickly becomes a reward for the sharpest tone. Before setting it, collect facts others can check. Each shows what waiting for the fix costs.
- The number of different customers who reported the same symptom, not the number of messages.
- A session recording showing the step where the customer got stuck and whether they gave up.
- Impact on the site goal: does the bug stand between a visitor and a purchase, booking or enquiry.
- A workaround that support can explain in a single message.
- An external deadline: a campaign, a season or an event the customer signed up for.
- Reach: one account, one browser, or every user.
Read report counts with care. Five messages from one person are still one case, and ten similar descriptions can hide two different faults. If the same symptom keeps coming back despite fixes, look for a shared cause with the guide to repeat support tickets. Watch recordings with a specific question, as described in how to analyze session recordings.
Who decides and when a bug gets an owner
Triage, the first review of new bugs, works best on a fixed rhythm, for example twice a week, with critical reports discussed immediately. This sequence suits a team of a few people.
- Confirm it is a bug.Compare the result with the agreed behaviour. If the customer is asking for something new, it belongs on a different list from fixes.
- Rate severity.The person who reproduced the bug does this, recording a level from S1 to S4 and one sentence of reasoning.
- Attach evidence.Linked tickets, a recording, goal impact and the workaround. Without them, priority stays provisional.
- Set priority.The person responsible for the work plan decides, not the author of the loudest message.
- Assign an owner.High priority gets an owner straight away. Low priority can wait in the backlog, but with a date for the next review.
The first step is covered by the guide on bug or feature request, because new scope should not compete with defects. The order of replies in the inbox is a separate matter: a ticket can have a high support queue priority because the customer needs a workaround, while the product fix itself is medium.
How to record both ratings in Meetlead Projects
In Meetlead Projects a task has the bug type, a priority (high, medium or low) and an assignee. You can link it to the customer ticket, a session recording and other tasks, and mark a later report of the same problem as a duplicate. The board and backlog can be filtered by priority, type or person. Projects have no separate severity field, so record severity as a fixed first line of the description.
Template for the first lines: "Severity: S2 - the booking is saved, the confirmation email does not go out. Workaround: support sends the confirmation manually. Evidence: 4 linked tickets, 2 recordings. Goal impact: none, bookings are being saved."
A person sets the priority; the product does not assess ticket content or assign it automatically. The task's change history shows who changed the priority and when, so a decision to postpone a serious bug stays traceable. Working in Projects requires an account, an active Projects app and the right permissions.
Questions about severity and priority
Can the customer set the bug priority? The customer is best placed to describe the impact on them: what they wanted to do, what they could not do and by when they need it. That is valuable input, but the team that sees all reports decides the order of fixes. Record their deadline as evidence, not as a ready-made priority.
How many priority levels does a small team need? Three are usually enough: now, the next work cycle, and the backlog. More levels breed boundary disputes. Keep improvements that are not bugs off this scale; a separate method fits them better, as described in the guide to prioritising UX fixes.
