What is a ship-blocker bug in game development?

A ship-blocker (also called a release-blocker or showstopper) is a bug severe enough that the game cannot be released with it present. Ship-blockers typically include crashes that affect more than a small percentage of players, bugs that make the game impossible to complete, data loss bugs like save file corruption, security vulnerabilities, and certification failures for console releases. The key distinction is that ship-blockers are not about severity alone but about whether the bug would make the release unacceptable to players or platform holders.

How do you decide when to mark a bug as 'won't fix'?

Mark a bug as won't fix when the cost of fixing it exceeds the benefit. This includes bugs that affect an extremely small number of players and have easy workarounds, bugs in systems that are being replaced in a future update, visual glitches that only appear in edge cases players are unlikely to encounter, and bugs where the fix carries a high risk of introducing new regressions close to release. Always document why a bug was closed as won't fix so the team can revisit the decision if circumstances change.

How often should you groom your game bug backlog?

During active development, groom the backlog weekly. During the final month before release, groom daily. Grooming means reviewing new bugs to set priority and milestone, re-evaluating bugs that have been in the backlog for more than two weeks without progress, closing duplicates, and reassessing priorities based on changing project needs. A backlog that is not groomed regularly becomes a graveyard of stale bugs that nobody trusts, which defeats its purpose as a planning tool.

How to Organize Your Bug Backlog for Game Releases

Quick answer: A ship-blocker (also called a release-blocker or showstopper) is a bug severe enough that the game cannot be released with it present.

Learning how to organize bug backlog for game releases is a common challenge for game developers. Your bug tracker has 347 open issues. Launch is in six weeks. Some of those bugs are crashes that will get you refunded on Steam. Some are cosmetic pixel offsets that nobody will ever notice. And you have no system for telling them apart at a glance. An unorganized bug backlog is worse than no backlog at all, because it creates the illusion of tracking without the ability to prioritize. Here is how to structure your backlog so that when launch pressure hits, you know exactly which bugs matter and which ones you can ship with.

The Milestone System

Every bug in your backlog should be assigned to one of four milestones. This is the single most important organizational decision you will make, and it needs to happen the moment a bug is triaged — not the week before launch.

Must Fix Before Launch: Bugs that will prevent you from releasing or will cause immediate negative reviews. Crashes, soft-locks (player gets stuck with no way to progress), data loss, and anything that breaks core gameplay. This list should be short. If it has more than 30 items a month before launch, you either have serious quality problems or your bar is set too high.

Should Fix Before Launch: Bugs that will noticeably hurt the player experience but will not prevent someone from completing the game. Visual glitches in key areas, audio issues, UI confusion, and gameplay balance problems. These are fixed after all must-fix bugs are resolved, time permitting.

Fix in First Patch: Bugs you are explicitly choosing to ship with, but plan to address within the first one to two weeks after launch. These must have low visibility or easy workarounds. Be honest about which bugs actually go here versus which ones will languish forever.

Backlog: Everything else. Minor visual issues, edge cases, platform-specific quirks, and nice-to-have improvements. No specific timeline. These get worked on when there is time, which often means never — and that is acceptable.

Identifying Ship-Blockers

Ship-blockers deserve their own tag or label, separate from the milestone system. A ship-blocker is any bug where the answer to "can we release the game with this bug present?" is an unambiguous no. The bar for ship-blocker status should be high and specific:

A crash that affects more than 1% of play sessions on any supported platform is a ship-blocker. A crash that only appears when you rotate the controller upside down during a loading screen is not.

Any bug that makes the game impossible to complete (progression blocker) is a ship-blocker. A bug that makes one optional side quest incompletable is usually not, unless it is a prominent one.

Save file corruption is always a ship-blocker. A save file that records a cosmetic item's color incorrectly is not.

For console releases, any bug that would fail platform certification is a ship-blocker regardless of severity.

// Example: Tagging ship-blockers in your bug tracker
// Use a clear, searchable label so the whole team can
// see ship-blocker status at a glance

Labels:
  [ship-blocker]  - Cannot release with this bug present
  [milestone:launch] - Must fix before launch
  [milestone:patch1] - Fix in first post-launch patch
  [milestone:backlog] - No specific timeline
  [wont-fix]      - Explicitly decided not to fix

Create a dashboard or saved filter that shows only ship-blockers. This becomes the team's daily check-in view in the weeks before launch. When that list reaches zero, you are ready to ship.

The Art of "Won't Fix"

Closing a bug as "won't fix" feels wrong to developers who care about quality. It should not. Every "won't fix" decision is a resource allocation decision: you are choosing to spend your limited time on bugs that matter more. The alternative is a backlog with hundreds of bugs that will never be addressed, creating noise that makes it harder to find the bugs that should be addressed.

Good candidates for "won't fix":

Bugs that require disproportionate effort relative to their impact. A visual glitch that only appears for one frame during a rare animation transition is not worth a week of animation system refactoring.

Bugs in systems being replaced. If you are rebuilding the inventory system for the next major update, fixing edge cases in the current inventory system is wasted effort.

Bugs with simple player workarounds. If restarting the level fixes the issue and the issue is rare, documenting the workaround may be more cost-effective than engineering a fix.

Bugs where the fix is riskier than the bug. Close to release, a risky fix that might introduce new regressions is often worse than the known bug it addresses.

Critical rule: Always document why a bug was closed as won't fix. "Won't fix: affects fewer than 0.1% of sessions, workaround is to reload checkpoint" is useful. "Won't fix" with no explanation is not. The documentation lets you revisit the decision later if circumstances change.

Backlog Grooming Cadence

An ungroomed backlog degrades fast. Bugs get duplicated. Priorities become stale. Bugs that were critical three months ago are now irrelevant because the feature was redesigned. Without regular grooming, the backlog becomes a landfill that nobody wants to look at.

During normal development: Groom weekly. Review all bugs created in the past week, assign milestones, merge duplicates, and re-evaluate any bugs older than two weeks that have not been started.

During the last month before release: Groom daily. Review the ship-blocker list, update milestone assignments based on remaining time, and make explicit "won't fix" decisions on bugs that will not realistically be addressed before launch.

After release: Return to weekly grooming. Add a post-launch triage pass to incorporate bugs reported by players and reprioritize based on what the actual player community cares about versus what the team assumed they would care about.

Each grooming session should take 15 to 30 minutes for a small team. If it takes longer, your backlog is too large or too disorganized, and you should spend one session doing a bulk cleanup: close everything older than six months that has not been touched, then start fresh with a clean list.

Practical Backlog Organization Tips

Use consistent labels across the team. If one person tags bugs as "crash" and another as "critical" and a third as "P0," your filters are useless. Agree on a shared vocabulary before the backlog grows.

Separate bug reports from feature requests. They have different prioritization criteria and different workflows. Mixing them in one backlog makes both harder to manage.

Attach reproduction steps to every bug. A bug without reproduction steps is a bug nobody will fix because nobody can find it. If a bug cannot be reproduced after two attempts, either add more context or close it and wait for it to be re-reported with better information.

Track bug velocity: how many bugs are being opened versus closed each week. If you are consistently opening more than you close, you are falling behind. This metric is especially important in the weeks before launch, where a rising bug count can signal that the release date is at risk.

"A backlog is a prioritized list of work, not a graveyard of good intentions. If a bug has been in your backlog for six months and nobody has touched it, it is not a plan — it is a wish. Close it or commit to it."

Related Issues

For a deeper dive into pre-launch bug management, see our guide on managing bug backlogs before launch. If you are in early access and struggling with prioritization, prioritizing bugs after early access launch covers that specific challenge. For the broader question of how to balance bug fixing with feature work, read when to fix bugs versus add features.

Ship-blocker count zero is your launch signal. Everything else is negotiable.