Bug severity vs priority
Severity measures how much damage a bug does when it happens. Priority measures how soon it should be fixed relative to everything else. They are set by different people for different reasons, and a bug can be high in one and low in the other.
The longer version
Severity is a property of the bug. It asks what breaks, for whom, and whether there is a way around it. A crash that loses unsaved work is severe whether it happens to one user a year or a thousand a day. Severity is usually set by whoever reproduces the bug, because judging it needs no knowledge of the roadmap.
Priority is a property of the schedule. It asks what should be fixed next, given everything else the team could be doing instead. Priority is set by whoever owns that trade-off, usually a product owner, and it can change without the bug changing at all: the same defect becomes urgent the week before a launch and can wait the week after.
The reason to keep them apart is that the interesting cases are the ones where they disagree. A typo in the company name on the pricing page is trivially severe and often top priority, because it is cheap to fix and embarrassing to leave. A data-corrupting edge case that needs an unusual sequence to reach is maximally severe and can still be scheduled behind a release, because almost nobody will hit it this week.
Teams that collapse the two into a single number lose that distinction and argue about the number instead. The argument is usually a proxy for the real disagreement, which is that one person is describing damage and the other is describing timing.
Common questions
Can a bug be high severity and low priority?
Yes, and it is common. A defect that corrupts data but only through a sequence almost no user performs is high severity, because the damage is serious, and can be low priority, because the schedule has more urgent work. The pair describes the bug honestly; a single score would not.
Who sets severity and who sets priority?
Severity is usually set by whoever reproduces the bug, since judging the damage requires only the bug itself. Priority is set by whoever owns the schedule, usually a product owner, since it is a comparison against all the other work in flight.
Can a bug be low severity and high priority?
A typo in the company name on the pricing page is the standard example: trivial in severity, since nothing stops working, and top priority, since it is embarrassing and takes minutes to fix. Priority weighs cost and timing against everything else in flight, so cheap, visible fixes often jump the queue ahead of damaging bugs that few users will reach this week.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.