Severity vs. priority: how to decide which bug to fix first

Every bug report answers two questions, whether it says so or not: how bad is it, and how soon do we fix it. The first is severity, the second is priority. They sound like the same thing, and on most projects they get mixed into one label like “urgent”. That is how a typo ends up blocking a release while a broken form waits until next week.

This post explains the difference, shows why the two often point in opposite directions, and how I use both to decide what gets fixed first.

Severity: how much damage the bug does#

Severity describes the bug itself: what breaks, for whom, and whether there is a way around it. It doesn't change with the calendar. A checkout that fails is just as severe on a Tuesday as on launch day. I use four levels:

1. Critical: the site or a core flow doesn't work and there is no workaround. The contact form fails silently, the checkout throws an error, pages return a 500.
2. Major: an important feature is broken or wrong, but there is a way around it. The mobile menu doesn't open on Safari, but the footer links still work.
3. Minor: something is wrong but doesn't stop anyone. A filter forgets its state after going back, an image is cropped badly at one screen size.
4. Trivial: cosmetic. A spacing that is 4 pixels off, a hover colour that doesn't match the design.

Severity is usually set by whoever finds and reproduces the bug: a tester, a developer, or me during QA. It is a technical assessment, so it should be the same no matter who writes it down.

Priority: how soon it gets fixed#

Priority describes the project, not the bug. It answers when the fix should happen, given everything else going on: the launch date, how many visitors are affected, what a campaign depends on, what the client promised to whom. The same bug can change priority overnight without changing at all.

• P1: fix now, everything else waits.
• P2: fix before the next release or launch.
• P3: plan it in, fix when there is time in the schedule.
• P4: nice to have. Fix it when you're already working on that part of the site, or close it.

Priority is a business decision, so it belongs to the client or project owner. My job is to give them what they need to decide: the severity, who is affected, and what the fix costs.

When severity and priority disagree#

If severity and priority always matched, you wouldn't need two fields. The interesting cases are the ones where they don't.

High severity, low priority#

The 2019 news archive throws a 500 error when you open page 14. Technically that's critical: the page doesn't work and there is no workaround. But nobody has visited it in months, it isn't linked from anywhere, and the archive is being removed in the redesign next quarter. It gets a P3, or gets closed when the archive goes.

Low severity, high priority#

The client's company name is misspelled in the hero headline. Nothing is broken, it's a one-word text fix, so the severity is trivial. But the campaign that sends traffic to that page starts tomorrow morning, and the headline is the first thing every visitor reads. That's a P1.

When they agree#

The contact form looks like it sends, but the email never arrives. Critical, because the site's main purpose is broken without anyone noticing, and P1, because every hour it stays live costs enquiries. On the other end: a footer icon 2 pixels lower than its neighbours on one tablet width is trivial and P4.

Severity is a fact about the bug. Priority is a decision about the project.

How I write it down#

Every bug I report gets both fields, plus enough detail that someone else can reproduce it without asking me. A short, consistent format saves more time than any tool:

## Contact form does not send emails

**Severity:** Critical (core flow broken, no workaround)
**Priority:** P1 (campaign traffic starts tomorrow)

**Steps to reproduce**
1. Open /contact/ on any browser
2. Fill in all fields and submit

**Expected:** confirmation message, email arrives at hello@example.com
**Actual:** confirmation message shows, no email arrives (SMTP auth error in the logs)

**Environment:** production, all browsers

The reason in brackets matters. “P1” on its own invites a discussion. “P1 because the campaign starts tomorrow” ends it, and makes it obvious when the reason no longer applies.

Working through the list#

When the list is long, the order of work follows priority first. Severity decides between bugs with the same priority. In code, that's a two-key sort:

type Severity = "critical" | "major" | "minor" | "trivial";
type Priority = "P1" | "P2" | "P3" | "P4";

interface Bug {
  title: string;
  severity: Severity;
  priority: Priority;
}

const PRIORITY: Record<Priority, number> = { P1: 0, P2: 1, P3: 2, P4: 3 };
const SEVERITY: Record<Severity, number> = { critical: 0, major: 1, minor: 2, trivial: 3 };

// Priority decides the order. Severity only breaks ties.
export function triage(bugs: Bug[]): Bug[] {
  return [...bugs].sort(
    (a, b) =>
      PRIORITY[a.priority] - PRIORITY[b.priority] ||
      SEVERITY[a.severity] - SEVERITY[b.severity],
  );
}

This also shows the most common mistake: sorting by severity alone. That's how a team spends launch day fixing the critical-but-irrelevant archive page while the misspelled headline goes live in front of everyone.

Severity also matters for when bugs are found: a critical bug caught during development is a quick fix, the same bug found by a visitor is expensive. I wrote about that in why bugs happen, and why finding them early is cheaper. How I test before a launch is in what QA means for a website.

The takeaway#

Keep severity and priority as two separate fields. Severity is set by whoever reproduces the bug and describes the damage. Priority is set by whoever owns the project and describes the timing. When they disagree, priority decides the order, and the reason behind it should be written down.

If your bug list has turned into a wall of “urgent” tickets, or you want someone to test your site and sort the findings before launch, get in touch. I'll tell you what to fix first and why.