Bug severity and priority calculator (free, no signup)
Severity is how badly a bug breaks things; priority is how soon it should be fixed. Answer four questions about impact, scope, workaround, and timing, and this free calculator recommends a severity and priority label with a justification you can paste straight into the ticket. It runs entirely in your browser, nothing you select is sent anywhere.
The definitions
Severity vs priority: what the difference is
Severity measures how badly a bug breaks things when someone hits it. Priority measures how soon the team should fix it. Severity is a property of the defect: data loss is critical whether it hits one account or a million. Priority is a property of the moment: who is affected, whether a workaround exists, and what the fix is holding up.
The two labels often disagree, and both mismatches are normal. A crash in a legacy export feature used by three accounts is high severity, low priority: bad when hit, rarely hit. A typo in your pricing page headline is low severity, high priority: nothing is broken, but every prospect sees it. If one label always follows the other in your tracker, one of them is not earning its keep.
The calculator below keeps the two judgements separate. Severity comes from the first question alone (what breaks); the other three (scope, workaround, timing) set the priority. Pick your answers, read the highlighted cell in the matrix, and copy the labels and justification into the ticket. Or send them straight to GitHub or Linear with the buttons under the result, no retyping.
This is the triage half of the job. For the report itself, the bug report template generator builds the full write-up, the steps to reproduce generator turns what you did into numbered steps a developer or a coding agent can replay, and the console log cleaner turns a raw console paste into deduped, grouped evidence for it.
Calculator
Set the severity and priority
Severity S2 (Major): a core feature is unusable. Priority P1 (High): it affects many users or a key segment, there is no workaround, and it blocks a release or a paying customer.
Add the repository as owner/repo, for example octocat/hello-world.
FAQ
Severity and priority questions
What is the difference between severity and priority in bug tracking?
Severity measures how badly the bug breaks things when someone hits it; priority measures how soon the team should fix it. They rest on different evidence. Severity comes from the defect itself: data loss is critical whether one person triggers it or a million do. Priority comes from context: who is affected, whether a workaround exists, and what the fix is holding up. The two labels often disagree, and that disagreement is useful information rather than a mistake. This calculator asks four questions and recommends both labels, with a justification sentence you can paste straight into the ticket.
Who sets severity and who sets priority?
Severity is usually set by whoever found and understood the bug, often a tester or the reporting engineer, because it is a technical judgement about impact. Priority is set by whoever owns the schedule, usually a product manager or the triage lead, because it is a business judgement about urgency. Keeping the two separate avoids arguments: the reporter is not claiming their bug jumps the queue, only describing the damage. On a small team one person wears both hats, and setting the labels separately still pays off, because it forces the impact question and the urgency question to be answered on their own terms.
Can a bug be high severity but low priority?
Yes, and the reverse too. A crash that loses data in a legacy export feature used by three accounts is high severity, low priority: bad when hit, but almost nobody hits it. A typo in the headline of your pricing page is low severity, high priority: nothing is broken, but every prospect sees it. The corner cells of the matrix above call both mismatches out. If your tracker forces one label to follow the other, you lose the ability to record either of these true things about a bug, and triage decisions get made on the wrong information.
What are the standard severity levels?
Most schemes use four: Critical (S1) for data loss, security holes, or a full outage; Major (S2) for a core feature that is unusable; Minor (S3) for a feature that works but is degraded; and Trivial (S4) for cosmetic problems. Priority usually mirrors that shape with P0 to P3, from drop everything down to whenever. The names vary between trackers (Jira ships Highest to Lowest, GitHub has no built-in field at all), but the four-level shape is close to universal and maps cleanly between tools, which is why this calculator uses it.
Is this severity and priority calculator free?
Yes. There is no signup and no limit. It runs entirely in your browser, nothing you select is sent anywhere. Pick the four answers, then copy the labels and the justification as Markdown, paste them into Jira or wherever you triage, or open them straight as a prefilled GitHub issue or Linear ticket. If you still need the report itself, the free bug report template generator on this site builds the full write-up around them.