Quick answer: Severity is a measure of a bug's technical impact, how badly it breaks things when it occurs (from cosmetic to game-breaking). Priority is a measure of how urgently it should be fixed relative to other work. They are related but independent: severity describes the bug, priority describes your decision about when to address it.
Severity and priority are two of the most useful fields on a bug, and two of the most commonly confused. People often treat them as the same thing, a synonym for "how important." But they measure different things, and keeping them separate makes your triage far more precise. The key insight is that how bad a bug is and how urgently you should fix it are related but not identical, and the cases where they diverge are exactly where good prioritization happens.
Severity: How Bad Is the Bug?
Severity describes the bug's impact, how much it breaks when it happens. It is largely a property of the bug itself, independent of your plans. A typical severity scale runs from critical (crashes, data loss, game-breaking) through major (a feature broken) and minor (a small malfunction) down to cosmetic (a visual blemish that does not affect function). Severity answers: when this bug occurs, how damaging is it?
Severity is relatively objective. A crash is high-severity whether or not you intend to fix it soon; a misaligned pixel is low-severity regardless of circumstances. It is a classification of the bug's nature, which is why it tends to be assigned based on the bug's effects.
Priority: How Urgently Should You Fix It?
Priority describes your decision about when to fix the bug relative to everything else. It is not just about the bug; it factors in how many players are affected, business impact, timing, and your other work. Priority answers: of all the things I could do, where does fixing this rank? A high-priority bug is one to fix soon; a low-priority one can wait.
Priority is more subjective and contextual than severity because it reflects judgment about your situation. The same bug might be high-priority before a launch and low-priority during early development. Where severity is mostly a property of the bug, priority is a property of your plan.
Why the Distinction Matters
The reason to keep them separate is that they diverge, and the divergent cases are the interesting ones. A high-severity bug can be low-priority: a game-breaking crash that only happens in an obscure scenario almost no one reaches is severe but not urgent. A low-severity bug can be high-priority: a cosmetic glitch on your store-page screenshot or splash screen is trivial in impact but worth fixing immediately because everyone sees it. Collapsing the two into one number hides these cases.
In practice, you often combine them, severity plus reach (how many players) drives priority. Bugnet's occurrence counts give you the reach data directly, so you can pair an assigned severity with the real number of affected players to set priority on solid ground. Tracking severity and priority as separate fields, informed by occurrence data, is what lets you make precise decisions like "severe but rare, so it waits" or "minor but everywhere, so fix it now."
Severity is how bad the bug is; priority is how soon you'll fix it. Keep them separate, severe-but-rare waits, minor-but-everywhere jumps the queue.