Bug severity levels explained

A shared severity scale lets beta testers, developers and product managers agree on how bad a bug is in seconds. Here is a simple four-level scale with examples, plus how severity differs from priority.

Who it’s for

  • Teams setting up a bug tracker for a beta
  • Beta testers who want to rate bugs consistently
  • Product managers triaging a long bug list

Updated 2026-10-19.

Bug severity levels give everyone the same words for how bad a bug is. Without a shared scale, beta testers call every bug critical and the team argues about each one. Below is a simple four-level scale with examples, a quick way to decide, and how to use severity during a beta test.

A four-level severity scale

S1 – Critical. The product or a core flow is unusable, data is lost or corrupted, money is charged wrongly, or private data is exposed. There is no workaround. Examples: signup fails for everyone; the app crashes on launch; saving a document deletes it; a user can see another user's data.

S2 – Major. An important feature is broken or gives wrong results, and the workaround is hard or unknown to most users. Examples: checkout fails when a coupon is applied; password reset email link is broken; the dashboard shows wrong totals; the mobile menu does not open on iPhone.

S3 – Minor. Something does not work as intended, but users can still do what they came for, or there is an easy workaround. Examples: a filter resets after a page reload; an error message is misleading; an image is stretched on tablet; sorting ignores case.

S4 – Trivial (cosmetic). No effect on function: visual polish, typos, alignment, wording. Examples: a typo in the footer; inconsistent button padding; an icon slightly off-center.

How to decide quickly

Ask three questions:

  1. Can users complete the task? No, and no workaround: S1 or S2.
  2. How many users are affected? Everyone, or only a rare setup?
  3. Is there harm? Lost data, wrong charges or exposed information push a bug to S1 regardless of how many people see it.

When unsure between two levels, pick the higher one and let triage lower it.

Assigning severity step by step

  1. Reproduce the bug and confirm the steps.
  2. Identify the affected flow. Is it signup, login, payment, the main task, or a secondary feature?
  3. Check for harm: data loss, wrong money, exposed private information. If yes, it is S1.
  4. Check for a workaround a normal user would find on their own. None: S1 or S2. Easy: S3.
  5. Estimate reach: all users, one browser or device, one plan or role.
  6. Write a one-line reason next to the severity, such as "blocks signup for anyone who mistypes their email".
  7. Review in triage, where the team sets priority.

Example: the same bug at two severities

Title: Dashboard: revenue total ignores refunds

Environment: Chrome on macOS, production, owner account
Steps to reproduce:
1. Create an order for 50.00 in test mode
2. Refund it in full
3. Open Dashboard > Revenue

Expected: total revenue shows 0.00 for the day
Actual: total revenue shows 50.00
Severity: S2 – Major
Reason: wrong totals in a key report; owners may make decisions on bad numbers
Frequency: Always

If the same wrong total also fed into invoices sent to customers, it would be S1: wrong money, real harm, no workaround. Severity follows impact, not the screen the bug appears on.

Severity is not priority

  • Severity describes impact on users. Testers can usually judge it.
  • Priority describes when the team will fix it, which also depends on business context, effort and timing.

A trivial typo in your pricing headline might be high priority before a launch. A major bug in a feature almost nobody uses might wait. Keep both fields in your tracker and let the team set priority during triage.

What to fix first

  • Now: every S1, and S2 bugs in signup, login, payment or the main flow.
  • This release: remaining S2 bugs, and S3 bugs that many users will hit.
  • Next releases: other S3 bugs.
  • When convenient: S4, except visible ones on high-traffic pages like the homepage, pricing or checkout.

Severity checklist for your team

Define

  • Four levels written down with a one-line definition each.
  • Two or three examples per level from your own product.
  • A rule that harm (data, money, privacy) always means S1.

Apply

  • Every bug gets a severity and a one-line reason.
  • Testers set an initial severity; triage confirms it.
  • Severity and priority are separate fields.

Use

  • Exit criteria reference severity, for example "no open S1 or S2 bugs in scope".
  • Counts of S1 and S2 bugs tracked per round or release.

Using severity in a beta test

  • Share the scale with beta testers in the welcome message.
  • Use severity in exit criteria, for example "no open S1 or S2 bugs in scope".
  • Re-check severity during triage; testers often over-rate cosmetic issues and under-rate data problems.
  • Track how many S1 and S2 bugs each round finds; it shows whether the product is stabilizing.

Common mistakes

  • Everything is critical. The scale stops meaning anything.
  • Mixing severity and priority in one field, so business decisions overwrite impact.
  • Rating by how annoying it is to the reporter rather than by impact on users.
  • Ignoring reach. A crash on one old browser is not the same as a crash for everyone.
  • Under-rating silent data problems, because nothing looks broken on screen.
  • Never revisiting severity after more information arrives.

Consistent severity: manual vs an AI beta tester

People assign severity differently, especially under deadline pressure. betatest.ing's AI beta tester assigns a severity to every finding, with a one-line reason, alongside steps to reproduce, an annotated screenshot and a recording when useful. Because it applies the same rules every run, including scheduled smoke and regression tests, it gives you a consistent baseline to compare rounds and releases.

Keep the final call with your team. Priority depends on business context the tester does not have, and some severe problems, such as ones that only appear on poor networks, with real payments, or for users of assistive technology, need people and dedicated audits to find and judge.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Test [YOUR APP URL] and rate every bug on this severity scale: S1 critical (core flow unusable, data loss, wrong charges or exposed data, no workaround), S2 major (important feature broken, hard workaround), S3 minor (works with an easy workaround), S4 trivial (cosmetic or wording). Focus on [THE FLOWS THAT MATTER MOST]. Use the saved test login, never make real payments (test mode only) and ask me before any irreversible action. Check desktop and phone width, forms, error messages and console errors. File each bug as a finding with its severity and a one-line reason, steps to reproduce, expected vs actual and an annotated screenshot; record anything S1 or S2. End with a report counting bugs by severity and listing all S1 and S2 bugs first.

Fill in your details

Here, or later in the chat with your tester.

  • [YOUR APP URL] The product to test.
  • [THE FLOWS THAT MATTER MOST] e.g. "signup, booking and payment in test mode".

What the AI beta tester checks

  • The flows that matter most, end to end
  • Data saving and loading correctness
  • Payment and upgrade flows in test mode
  • Error messages and validation
  • Desktop and phone-width layouts
  • Console errors and failed requests
  • Cosmetic issues and typos (rated S4)

What you get

  • Every bug rated S1 to S4 with a one-line reason
  • Steps to reproduce and annotated screenshots
  • Recordings of every S1 and S2 bug
  • A report with counts by severity, worst first

How to run it with betatest.ing

  1. Add your app as a project with a test login.
  2. Name the flows that matter most in the task.
  3. Send it and triage the S1 and S2 findings first.
  4. Rerun after fixes to confirm the counts go down.

Tips

  • Data loss, wrong charges and exposed data are always S1.
  • When unsure, rate higher and let triage lower it.
  • Keep a separate priority field; do not overload severity.

Bug severity levels: FAQ

What are the levels of bug severity?

A common scale has four: critical (S1), major (S2), minor (S3) and trivial or cosmetic (S4). Some teams add a fifth level, but four is easier to apply consistently.

What is a critical bug?

One that makes the product or a core flow unusable with no workaround, or that causes data loss, wrong charges or exposure of private data.

What is the difference between severity and priority?

Severity is impact on users; priority is when the team fixes it. A cosmetic bug can be high priority, and a major bug in a rarely used feature can wait.

Who sets bug severity?

The reporter suggests it and the team confirms it during triage. A shared, written scale keeps ratings consistent.

Is a typo ever a high-severity bug?

Its severity is usually trivial, because it does not affect function. Its priority can still be high, for example a typo in the price on your pricing page or in a legal notice. That is why severity and priority are kept as separate fields.

What severity is a security bug?

Anything that exposes private data or lets one user act as another is usually S1, critical, regardless of how many people are affected. Handle it privately rather than in a public bug list, and fix it first.

How many severity levels should we use?

Three to five levels work for most teams; four is a common choice because it separates broken features from minor and cosmetic issues without endless debate. What matters most is that each level has a clear definition and examples everyone agrees on.

Related beta testing guides

  • How to write a bug report — A good bug report lets a developer reproduce the problem in minutes without asking a single question. Here is what to include, how to write each part, and an example you can copy.
  • Bug report template — A good bug report lets a developer reproduce the problem on the first try. This template has every field that matters and nothing extra. Give it to your beta testers, or ask your AI beta tester to file every bug in exactly this format.
  • Regression testing after deploys — Regression testing checks that what worked yesterday still works after today’s change. For small teams shipping often, a short regression suite run after every deploy prevents most "it used to work" bugs from reaching users.
  • How to write a beta test plan — A beta test plan is a one or two page document that says why you are running the beta, what gets tested, by whom, how bugs are reported and when it ends. Writing it takes an hour and saves weeks of unfocused feedback.
  • Free tool: Bug severity calculator — Six questions → severity, priority and a one-line justification for the ticket.

More in guides