Stephen Brenish
Bug backlogs in games grow faster than teams can fix them, and they grow fastest at the worst possible moment: the final months before ship, when every system is finally running together. If triage cannot keep up, bugs pile up unprioritized, and decisions that should have been made calmly get made in bulk under certification pressure.
The bottleneck is rarely filing. Teams can file bugs all day. It is the gap between a bug being filed and someone deciding how severe it is, how urgent it is and who owns it. That gap is where triage lives.
Triage is not fixing
The most common way triage collapses is when it turns into problem-solving. Triage answers four questions about every incoming report, and nothing else:
- Does it reproduce?
- How severe is it?
- How urgent is it relative to everything else?
- Who owns it?
The moment a triage meeting starts discussing solutions, it doubles in length and throughput collapses. Solutions belong with the owner after triage.
Triage is also not a democracy. When every severity call becomes a committee debate, the person whose system is implicated tends to argue the rating down. Good triage has one accountable decision-maker, usually the QA lead or a producer, and everyone else contributes information, not votes.
Separate severity from priority
Severity is how bad the bug is. Priority is how soon you will fix it. They are related but not the same: a rare crash in an obscure menu can be high severity and lower priority, while a cosmetic glitch on the title screen can be low severity and high priority.
| Severity | Meaning | Example |
|---|---|---|
| S1 Critical | Crash, hang, data loss, progression blocker, certification failure | Save corruption; a soft lock in the main quest |
| S2 Major | Major feature broken or badly degraded, no reasonable workaround | Multiplayer matchmaking fails for some regions |
| S3 Moderate | Feature works with a workaround or noticeable issues | A UI element overlaps text in one language |
| S4 Minor | Small functional or visual issue | A texture seam visible in one area |
| S5 Trivial | Polish or suggestion | A slightly late sound cue |
Then set priority separately, based on schedule, player impact and risk. Write both definitions down and use the same ones across every discipline.
The rhythm: daily intake, weekly review
Game Production Stages · Timothy Cain on YouTube
Daily triage handles new intake, in a short standing meeting. The owner pre-sorts overnight reports beforehand, flagging obvious S1 and S2 issues and moving clear low-severity items to a probable-backlog lane, so the meeting only debates the genuinely ambiguous reports.
Weekly review handles reprioritization: anything that escalated, anything that has been sitting too long, and how the overall bug curve compares with the milestone plan. Keeping the two separate stops the daily meeting from sprawling.
Filing standards decide everything downstream
Tool choice matters far less than filing discipline. A team with mandatory reproduction steps, consistent severity tags and a “screenshot or video, or it didn’t happen” rule will out-process a team with expensive tooling and lax filing every time. A good template includes:
- A specific title (what, where, when)
- Build number and platform
- Exact reproduction steps and how often it reproduces
- Expected versus actual result
- Severity as the reporter sees it, confirmed in triage
- Attachments: video, screenshot, log, save file if relevant
Tools
Jira remains the most common bug tracker at larger studios, with custom fields for severity, platform and certification flags. Linear is faster and lighter for small teams. Hansoft and similar production tools matter when bug data needs to feed straight into the production schedule. Whatever you use, configure the fields once, enforce the template, and keep the workflow simple enough that people actually follow it.
Write the policy down
Most studios have an informal triage culture and no written policy, so the process degrades whenever the person who holds it in their head is away. A one-page triage policy should cover the severity and priority definitions, who owns triage and who is their backup, the meeting rhythm, the filing template, and the ship policy for bugs that will not be fixed.
That last part matters most near launch. Decide your bug bar for each milestone in advance, as part of the milestone’s exit criteria, so that certification and gold decisions are about applying a rule rather than negotiating one. The console certification checklist covers the issues platform holders test for, and alpha, beta and gold explained covers where the bug bar tightens. For the QA side of the pipeline, see the QA testing workflow for indie games.
Photo: Seraphfim Gallery via Pexels
