Bug Severity vs Priority: Differences, Examples and a Free Matrix

Bug severity vs priority is the difference between how bad a bug is and how soon it gets fixed. When a team keeps both in one field, the loudest "urgent!!" wins, a typo in a footer sits next to a broken checkout and nobody can explain why one was fixed before the other. The definitions, the website examples and the free matrix below give every bug two separate answers, with a written reason when they disagree.

What is the difference between bug severity and priority?

Bug severity is the degree of impact a bug has on the people using the site or the system behind it; bug priority is the order in which the team will fix it. Severity describes the bug. Priority describes a decision about the bug, and that decision depends on things the bug itself doesn't know: the launch date, the client's campaign, how many visitors use the page.

The ISTQB testing glossary draws the same line: severity is about the impact of a defect, priority about its business importance. In practice the two are set by different people, at different moments, with different information.

Keeping them apart turns an argument into two short conversations. Severity is a question of fact ("does the form lose the message or not?"), and it can be checked against the screenshot and the steps. Priority is a question of judgment ("is this more important than the menu bug before Friday's review?"), and it belongs to whoever owns the schedule.

Bug severity levels, with website examples

Four levels cover almost every team: critical, major, minor and trivial. Rate severity on what the bug does to one person who runs into it. How many people run into it, and when, belongs to priority; mixing reach into severity is what makes a crash on an old page and a crash in checkout look the same.

Two rules keep the scale honest. Write one real example from your own projects next to each level, so new testers calibrate against something concrete. And reproduce before you rate: a "critical" bug that only happens with a browser extension installed usually isn't.

Priority levels: when the bug gets fixed

Priority says when, so define each level by what the team does, not by how anyone feels. Four levels map cleanly onto a website project's rhythm of review rounds, launch and maintenance.

The targets are examples; agree your own and write them down, because a P1 that waits three days teaches everyone to ignore the scale. The Jira column uses Jira's default priorities, Highest to Lowest, which a Jira admin can rename or extend.

Severity and priority examples: when they disagree

Most of the time the two move together: a broken checkout is critical and gets fixed first, a misaligned icon is trivial and waits. The cases worth discussing are the other two, where a severe bug can wait and a trivial one can't.

The misspelled company name is the classic case. No feature is broken, so its severity is trivial. But the client reviews the site tomorrow, the fix takes two minutes and leaving it signals carelessness on every page view, so it jumps the queue. The archive error is the reverse: anyone who opens that page sees nothing at all, yet fixing it this week would delay fixes that affect real visitors, so it gets scheduled rather than ignored.

Recording both values is what keeps the second case safe. A P3 with severity Major is visibly different from a P3 with severity Trivial, and it gets picked up once the launch is out of the way.

How does a bug severity matrix work?

A bug severity matrix is a grid that crosses severity with a second factor, usually business urgency, so that each combination suggests a default priority. The tester's rating and the business context meet in one cell, and the team starts triage from a suggestion instead of a blank field.

Business urgency needs its own three levels, written down like severity:

• High: a key page or flow (home, checkout, contact, booking, login), most visitors, the client's brand, or a date that can't move.
• Medium: a page or feature people use regularly, with a workaround and no deadline depending on it this week.
• Low: few people affected, such as an old page, an unusual device or browser, or admin screens only.

The matrix in the template uses these defaults:

In the Excel file, the Bug log sheet reads this grid: pick a severity and an urgency from the dropdowns and the Suggested priority column fills itself in. Change any cell on the Matrix sheet and every suggestion follows, so the grid can reflect your own rules.

The matrix suggests; a person decides. Next to the suggestion there is a Final priority column and a "Reason if different" column. In the example rows, the misspelled company name comes out as P2 from the matrix and is overridden to P1 with the reason "client reviews the site tomorrow; two-minute fix". Overrides with a written reason are healthy. Overrides without one, every week, mean the matrix needs adjusting.

Who sets severity and who sets priority?

The person closest to the bug rates severity, and the person who owns the schedule sets priority. On a website project that usually splits like this:

• The reporter (client, tester, colleague) describes what happened and what it stopped them doing. They can suggest a severity, but they don't set it.
• The tester or developer reproduces the bug and confirms the severity.
• The project manager, product owner or team lead sets priority during triage, and for client work agrees the top items with the client.

Clients deserve a note of their own. To a client, the bug they just found is the most important one, so "urgent" in a client email tells you about their mood, not the bug's severity. Ask what they were trying to do and whether it stops them or their customers, rate it yourself, and show them the priority you gave it. A client who sees their typo listed as P1 for tomorrow rarely argues about the server error on an old page staying at P3. Our guide on what to put in a bug report covers the questions to ask so the report carries the facts severity depends on.

Common mistakes with severity and priority

Most problems come from treating the two fields as one, or from never writing down what the levels mean:

• One field for both. The team can no longer tell "bad but rare" from "minor but visible", and the reporter's adjective decides the order.
• Everything is critical. If most open bugs are P1, the scale has stopped meaning anything; re-rate the list against the written definitions.
• Reach inside severity. "Only one user hit it" lowers the priority, not the severity: the next user who hits it gets the same broken page.
• Priority set once and never revisited. A P3 before launch can become P1 the week a campaign sends traffic to that page.
• Rating without evidence. Severity arguments are usually missing-information arguments; a screenshot, the URL and the browser end most of them.

If you test a site before launch with a checklist, rate each failed check the same way; the website QA checklist has a notes column that works well for it.

Severity and priority in Jira and other trackers

Jira has a Priority field built in, with Highest, High, Medium, Low and Lowest as defaults, but no Severity field, so teams add a custom select field with Critical, Major, Minor and Trivial or use labels such as severity-critical. Map the template's P1 to P4 onto Highest to Low, and keep Lowest unused or for "won't fix unless someone asks again".

In trackers with no severity concept at all, one label or tag per level does the job, as long as everyone uses the same four words. Whatever the tool, set both values when the bug is triaged, not when it's reported: the reporter rarely has the context for priority.

If client reports reach Jira through the GiveFeedback.io Jira integration, each one arrives as an issue with the report's title as the summary, the client's description, the page URL and the browser details, and the annotated screenshot attached. You add the priority, the severity field or label and the assignee in Jira as usual.

How do you rate severity faster?

Give whoever triages the evidence up front. Most of the time spent rating a bug goes into finding out what happened: which page, which browser, what the screen showed, whether an error appeared in the console. When the report already contains that, rating severity takes seconds.

That is what GiveFeedback.io is for. Clients and testers click a "Give Feedback" button on the site, mark up a screenshot of what they see and write what happened, without creating an account. Every report arrives with the page URL, the browser and version, the operating system, the screen resolution and a log of the page's console messages, errors and failed requests. A "checkout broken" report with a red error in its console log and a failed payment request is easy to rate Critical; the same words with a clean log and a screenshot of a slow spinner point somewhere else.

Reports land in a dashboard with Open, Resolved and Archived statuses, or go straight to Jira, Trello, ClickUp, Asana, monday.com, Wrike, Notion, Slack, Discord or email. The Free plan covers 5 projects and 50 feedback reports; pricing has the rest.

Write your four severity definitions this week, put a real example from your last project next to each, and run the next triage from the matrix. Within a couple of review rounds, "why was this fixed first?" becomes a question with a written answer.