How to Organize Bug Reports by Severity and Priority

Learning how to organize bug reports by severity is a common challenge for game developers. You have 200 open bugs and two weeks until launch. Fixing all of them is impossible. Fixing the wrong ones is worse than fixing none at all. The difference between a successful launch and a disaster often comes down to one skill: knowing which bugs to fix first. That requires a system for organizing bugs by severity and priority—two concepts that sound similar but work very differently.

Severity vs. Priority: The Critical Distinction

Severity and priority are the two axes of bug triage, and confusing them is the most common mistake in bug management. Severity is the technical impact of the bug. How bad is the damage when the bug occurs? Priority is the business urgency. How soon does this bug need to be fixed?

These are independent dimensions. A crash in a hidden debug menu has high severity (it is a crash) but low priority (no player will ever trigger it). A misspelled game title on the main menu has low severity (it is cosmetic) but high priority (every single player sees it on launch day).

When you combine severity and priority into a single field—as many small teams do—you lose the ability to make this distinction. A bug gets labeled "critical" and you cannot tell if that means "the game crashes" or "the marketing team needs it fixed by Tuesday." Keep them separate.

The Game-Specific Severity Hierarchy

Severity for games follows a clear hierarchy based on the type of damage the bug causes. From most to least severe:

S0 — Crash / Data Loss. The game terminates unexpectedly, or player data (save files, progress, purchases) is destroyed or corrupted. This is always the highest severity because the player loses not just their session but potentially hours of progress.

S1 — Softlock / Progression Blocker. The game does not crash but the player cannot continue. They are stuck in a room with no exit, a required item cannot be picked up, or a scripted event does not trigger. The player’s only option is to reload a save or restart entirely.

S2 — Gameplay Bug. A game mechanic does not work as intended. Damage calculations are wrong, an ability does not activate, enemy AI behaves incorrectly, or physics interactions produce unexpected results. The player can continue but the experience is degraded.

S3 — Visual / Audio Glitch. Something looks or sounds wrong. Textures flicker, animations play incorrectly, sound effects are missing or distorted, UI elements overlap. The player notices but gameplay is unaffected.

S4 — Cosmetic / Polish. Minor visual imperfections. A pixel is off, a color is slightly wrong, text alignment is inconsistent, an animation is not perfectly smooth. Most players will not notice.

# Example bug entries with severity assigned

[S0] Game crashes when loading level 5 on Intel GPUs
     Affects: ~15% of players (Intel integrated graphics)
     Repro: Load any save in level 5 on Intel UHD 620+

[S1] Door to boss room does not open after collecting all keys
     Affects: 100% of players on the critical path
     Repro: Collect all 3 keys in any order, approach boss door

[S2] Fire spell does ice damage when cast during rain
     Affects: Players using fire spell during weather events
     Repro: Cast fire spell while rain particle system is active

[S3] Player shadow renders on top of player during cutscenes
     Affects: All players during cutscenes
     Repro: Trigger any cutscene, observe shadow layering

[S4] Inventory grid has 1px gap on right side at 2560x1440
     Affects: Players at 1440p resolution
     Repro: Open inventory at 2560x1440, inspect right edge

The P0-P3 Priority Framework

Priority is where business context enters the equation. A bug’s priority depends on how many players are affected, where in the game it occurs, and how close you are to a release deadline.

P0 — Critical. Drop everything and fix this now. Ship a hotfix if it is in production. P0 bugs are: crashes affecting more than 1% of players, data loss or save corruption under any conditions, security vulnerabilities, and softlocks on the critical path that affect 100% of players.

P1 — High. Must be fixed before the next planned release. P1 bugs are: crashes affecting a small but meaningful number of players, gameplay bugs on the main path, severe performance problems on supported hardware, and broken progression in required content.

P2 — Medium. Should be fixed when capacity allows. P2 bugs are: gameplay bugs in optional content, visual glitches that are noticeable but not disruptive, minor UI issues, and edge cases that require specific but plausible conditions to trigger.

P3 — Low. Fix if there is nothing higher-priority to work on. P3 bugs are: cosmetic issues most players will not notice, edge cases requiring unusual or unlikely inputs, bugs in deprecated features that are scheduled for removal, and issues that only occur in unsupported configurations.

How Severity and Priority Interact

The power of having two separate dimensions is that you can handle the non-obvious cases correctly:

High severity, low priority: A crash that occurs only when the player has exactly 999 items in their inventory and opens the sort menu while falling off a cliff. It is technically a crash (S0), but the conditions are so unlikely that it is P3. Document it as a known issue and fix it when you have spare capacity.

Low severity, high priority: A typo in the tutorial that tells players to press "X" when the correct button is "A." It is cosmetic (S4), but it confuses 100% of new players in the first minute of gameplay. On launch day, this is P0 because first impressions matter more than anything.

High severity, high priority: The obvious case. A crash on the main path affecting most players. Fix it immediately.

Low severity, low priority: A subtle visual artifact in a hidden area. Track it and forget about it until you run out of real problems to solve.

Re-Prioritization as Launch Approaches

Bug priority is not static. As your launch date approaches, priorities shift. Here is how to re-triage effectively:

Two months before launch: prioritize by severity. Fix the most damaging bugs regardless of where they occur in the game. This is when you should be tackling the hard crashes and data loss issues that require significant engineering effort.

Two weeks before launch: shift priority toward the early game. Any bug in the first 30 minutes of gameplay gets a priority boost because launch-day players will all be in that section simultaneously. Late-game bugs can wait for a post-launch patch because players will not reach that content for days or weeks.

Launch day and beyond: let crash data drive priority. Your assumptions about which bugs matter most will be tested against reality. A bug you rated P3 because you thought it was rare might turn out to affect thousands of players on a hardware configuration you did not anticipate. Re-triage weekly based on actual occurrence data from your crash reporting system.

# Priority re-evaluation checklist (run weekly before launch)
# For each open bug, ask:

1. Does this affect the first 30 minutes of gameplay?
   If yes, consider promoting to P1 or P0

2. Does fixing this bug carry regression risk?
   If yes and launch is < 2 weeks away, consider demoting

3. Has the affected player count changed since last triage?
   If crash data shows increasing occurrences, promote

4. Is this bug in content that launch-day players will reach?
   If no, demote to P2 or P3 for post-launch patch

5. Would shipping with this bug generate negative reviews?
   If yes, promote regardless of technical severity

Keeping Your Bug Backlog Organized

A severity and priority system only works if it is consistently applied. Here are practical guidelines for maintaining it:

Assign severity at creation time. The person who files the bug assigns severity based on the technical impact. This should rarely change because the technical impact of a bug does not change.

Assign priority during triage. Priority is set during a team triage session, not by the individual filing the bug. A single person deciding priority will over-prioritize the bugs they personally care about. A team decision balances perspectives.

Re-triage regularly. For active development, triage weekly. For a stable live game, triage when new crash data arrives or when planning a patch. Stale priorities are dangerous because they create a false sense of order.

Close bugs that will never be fixed. Be honest about P3 bugs that have been in the backlog for months. If you are never going to fix a 1px alignment issue at an obscure resolution, close it. A backlog full of noise makes it harder to find the signal.

"Severity tells you how bad the bug is. Priority tells you how much you should care right now. The bugs that ruin launches are the ones where the team got those two things confused."

Related Issues

For a deeper look at triage workflows after your game goes live, see our guide on how to prioritize bugs after early access launch. If you are a solo developer setting up your first bug tracking process, our article on bug tracking tools for solo developers covers lightweight systems that support severity and priority fields. For connecting crash data to your priority decisions, see our guide on adding crash reporting to your game.

Severity is what the bug does to the player. Priority is what the bug does to your schedule. Never confuse the two.