Bug triage
Bug triage is the recurring process of reviewing newly reported bugs and deciding what happens to each one: whether it is valid, how bad it is, how soon it should be fixed, and who owns it. It is a sorting step, not a fixing step.
The longer version
The word is borrowed from emergency medicine, and the analogy holds: the point is not to treat everything, it is to decide the order in which things get treated. A triage pass takes a queue of unsorted reports and turns it into a ranked, assigned, deduplicated list. Reports that cannot be reproduced or that describe intended behaviour leave the queue here rather than sitting in it for a quarter.
The decision on each ticket is made as the ticket arrives ready, by whoever can make the call: usually a QA lead, an engineering lead and a product owner between them. Teams that also keep a short standing meeting, often weekly, reserve it for the disputed cases, where two engineers or two customers want the same slot, and the queue is its whole agenda.
Four decisions come out of a triage pass for each report. Is it real and reproducible. How severe is the damage if it is left alone. How urgent is the fix relative to everything else in flight. Who owns it next. The second and third are separate questions, and conflating them is the most common way triage goes wrong: see severity and priority.
What makes triage slow is almost never the deciding. It is the reports that arrive without enough information to decide on, which send the meeting into a round of asking the reporter what browser they were on and what they clicked. A report that arrives with its evidence attached is triaged the day it lands.
Common questions
How often should a team run bug triage?
Each ticket gets its decision when it arrives ready, with its evidence and a severity already on it, rather than waiting for a weekly clock: the lead assigns and prioritises on the board as reports come in. A weekly meeting still earns its slot, but only for the contested cases, such as two engineers wanting the same bug or two customers promised the same sprint.
Who should be in a bug triage meeting?
Whoever can make all four decisions without a follow-up: someone who can judge technical severity, someone who can weigh it against the roadmap, and someone who can assign the work. In practice that is usually an engineering lead, a product owner and QA. Adding more people makes the meeting longer without making it more decisive.
What is the difference between bug triage and bug tracking?
Tracking is the record of a bug over its whole life, from report to closure. Triage is one recurring step inside that life, where an untriaged report is assessed and ranked. Tracking is a system; triage is a decision made repeatedly inside it.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.