Severity vs Priority

Severity is about the bug itself: does it crash the app, corrupt data, block a core flow — or is it a one-pixel misalignment? It's usually judged by whoever finds or triages the bug, based on technical impact.

Priority is about the response: how soon should this get fixed relative to everything else in the backlog? It factors in severity, but also who's affected, whether there's a workaround, and what else is planned.

Where they diverge

• High severity, low priority. A crash in a rarely-used admin tool during an internal-only beta might be severe but not urgent.
• Low severity, high priority. A typo in the pricing page on launch day is cosmetic but needs fixing now.

Treating severity and priority as the same field is a common source of bad triage — the loudest bug report gets fixed first regardless of actual impact. Track them separately, even if your tracker only exposes one field; note the other in a comment.

In practice

A defect's severity and priority both feed into where it sits in the defect life cycle and whether it blocks release under your entry and exit criteria.