Open any bug tracker and you will find the same four words: low, medium, high, critical. They are so standard that nobody questions them. They are also, for most teams, wrong — not because four is the wrong number, but because the words are somebody else's.
A priority scale is a shared decision, compressed
The point of a priority field is not to describe the bug. It is to answer one question for whoever reads the board next: do I work on this before the thing I was going to work on?
That makes a priority level a compressed agreement. "Critical" means something specific in your team — maybe "page someone", maybe "ships in the next patch", maybe "stop the release". The word only works if everyone decompresses it the same way.
Which is exactly why a generic scale degrades. Nobody agreed on what your tracker's "high" means, so each person supplies their own definition, and the field stops carrying information.
The two questions people confuse
Most arguments about priority are actually arguments about two different questions:
Severity: how bad is the failure? A crash is severe. A misaligned icon is not.
Priority: when will we fix it? A misaligned icon on the pricing page an hour before a launch is urgent and not severe.
A single field cannot hold both, and teams that try end up with a scale that means severity on Mondays and priority on Fridays. Pick one — for most product teams, priority is the useful one, because it is the one that changes what you do next — and if you genuinely need both, make severity a separate field.
How many levels
Fewer than you think.
The failure mode of a long scale is not that people choose wrong; it is that they stop choosing. Given P0 through P4, most teams use P1 and P3 and quietly abandon the rest. You have a five-level scale doing the work of two.
A test: for each adjacent pair of levels, can you state a rule that decides between them without thinking? If "high" and "medium" only differ by feel, they are one level wearing two names.
Three levels that people apply consistently beat five that they guess at. Four is a common landing spot because it gives you two flavours of "soon" and two of "later".
The other rule is that the top level has to be rare. If a third of the board is critical, the word has been redefined as "I care about this," and the board no longer tells you where to start. A useful top level describes something you would interrupt work for — which, by construction, cannot be a third of anything.
Name them the way your team talks
If your standup says "is this a blocker?", then Blocker should be a value in the tracker. Every translation step between how people speak and what the tool offers is a place where the field gets filled in wrong or skipped.
This is the strongest argument for editable priorities, and it has nothing to do with flexibility for its own sake. It is that a field people can answer in their own vocabulary is a field they will actually answer.
Some scales worth stealing:
Support-led teams: Blocker · Urgent · Normal · Low — maps cleanly onto an SLA.
Product teams: Now · Next · Later — three levels, no ambiguity, doubles as a roadmap.
Incident-shaped work: P0 · P1 · P2 — if your on-call runbook already uses these numbers, use the same ones here.
Editing the scale in BugDump
BugDump starts every project with Low, Medium, High and Critical, and none of them is fixed. On the Properties page, select Priority and edit the list: rename in place, recolour, add your own, delete what you do not use.
A rename carries to everything at once. Tasks already marked Critical show the new word on their cards, in the task panel, on the public portal and through the MCP server — there is no migration and no re-tagging, because the task points at the option rather than storing a copy of its name.
Deleting a level keeps its tasks; they simply lose that priority. So pruning a scale you over-designed is cheap, which matters, because most teams only discover the right scale by running the wrong one for a month.
The board filters by whatever your list holds, several at a time.
Two things to watch when you rename
Anything that sets a priority by name. An embedded widget passing priority: 'critical', or a script hitting the API. Matching ignores case, so critical still finds Critical — but if you rename Critical to Blocker, the old name matches nothing. Anonymous reports still arrive, just without a priority; authenticated calls are rejected so you notice.
Integrations that map to their own severities. Jira and Freshdesk have their own scales, and a level you invented has no equivalent, so those tickets get the destination's middle severity. If that mapping matters, add levels rather than renaming the defaults.
The honest summary
Priority is a small field that decides the order of everything else, and it only works when a team has genuinely agreed what each level means. Fixed vocabulary gets in the way of that agreement. Let the tracker learn your words instead.
Then use the scale with some discipline: keep the top level rare, delete the level nobody picks, and revisit it after a month of real bugs.
Read next: Bug Tracking Metrics That Actually Matter and How to Triage Bugs Faster.