Severity / Priority Calculator
Weighted inputs across 7 factors produce a suggested Severity, Priority (P1-P4), and plain-English rationale.
Runs 100% client-sideOn this page4 sections
User Impact
How many users are affected and how severely?
Business Impact
Damage to revenue, reputation, or operations?
Frequency
How often does this bug occur?
No Workaround
No acceptable workaround exists?
Data Loss Risk
Could this cause data corruption or loss?
Security Risk
Could this expose a security vulnerability?
Revenue Blocker
Directly blocks checkout, payments, or sales?
HOW TO USE
- 01Rate each of the seven factors — user impact, business impact, frequency, workaround, data-loss, security, and revenue.
- 02Click Calculate to get a suggested Severity, a Priority label (P1–P4), and a plain-English rationale.
- 03Copy the rationale sentence straight into your ticket to justify the rating.
Try it
Checkout broken on mobile: high user + revenue impact, no workaround → expect High / P1WHEN TO USE
Use this calculator when you need to justify or calibrate a defect's Severity and Priority before filing it. Rate seven weighted factors -- user impact, business impact, frequency, whether a workaround exists, data loss risk, security exposure, and revenue impact -- and the calculator returns a suggested Severity (Low/Medium/High/Critical), a Priority label (P1-P4), and a plain-English rationale sentence you can paste directly into your ticket.
WHAT BUGS THIS FINDS
Severity/Priority mismatch
Defects labelled Critical/P3 or Low/P1 without justification, causing sprint confusion.
Under-reported high-impact bugs
Bugs affecting revenue or data integrity filed as Medium because 'it has a workaround'.
QA USE CASES
Calibrating a new defect before triage
Score the 7 factors → confirm or adjust Severity/Priority before submitting
Justifying escalation to a stakeholder
Share the rationale sentence to explain why a bug is P1 and not P2
Comparing two defects for sprint prioritisation
Run both through the calculator → compare weighted scores
Onboarding new QA engineers
Use as a learning exercise to understand severity vs priority distinctions