Bug triage process flowchart

How it works

1. Rename the lanes to the roles you have

   Replace Reporter, Support, Triage lead, Engineering and QA with your real functions. Small teams often merge support and triage into one lane, and a team without a dedicated QA function usually moves verification to a second engineer. Use one lane per decision-maker rather than per person, or the chart stops matching reality as soon as someone changes job.

2. Write your severity and priority definitions onto the triage step

   Severity is the impact if the defect occurs; priority is when it will be worked on. Define each level with a worked example, for example data loss or a blocked checkout at the top and a cosmetic misalignment at the bottom. Without examples every report arrives at the highest level and the field stops carrying information.

3. Set the escalation threshold

   Replace the generic "Critical or production down?" decision with your real trigger: customers affected, a revenue path blocked, data at risk. Name who is authorised to declare an incident and where the incident process lives, because triage hands the defect over at that point while the defect record stays open for the permanent fix.

4. Decide how long the information loop runs

   The "Reporter responds in time?" decision needs a stated waiting period and usually one chase. Put the number on the step. Without it, reports that were never reproducible stay open indefinitely and the backlog stops reflecting real work.

5. Agree what verification means and where a reopen goes

   State whether QA verifies against the reporter's original steps, a regression suite, or both. This template routes a failed verification back to development on the same record so the history stays in one place. Change it to loop back to triage instead if a reopened defect should be re-prioritised rather than picked straight back up.

6. Publish it and keep one current version

   Put the chart next to the bug report form and in the on-call runbook, capture sign-off from support, engineering and QA, and keep the earlier versions so you can see when the process changed. Revisit it after any defect that took far longer to resolve than it should have, and fix the step where it stalled.

Frequently asked questions

What are the stages of a bug triage process?

Five, in most teams. Intake, where the report is logged with enough detail to act on. Reproduction, where support confirms the defect exists and is not a configuration or user error. Triage, where duplicates are linked and severity, priority and an owning team are assigned. Fix, covering development and code review. Verification, where QA checks the fix against the original report before it is released and the reporter is told. The chart above uses those five as its phase columns, with reproduction and triage carrying the decisions that do most of the work.

What is the difference between severity and priority?

Severity describes the impact of the defect: data loss, a blocked workflow, a cosmetic issue. Priority describes when it will be worked on. They answer different questions and should stay separate fields. A typo in a published price is low severity and high priority; a crash in a feature two customers use can be high severity and low priority. Collapsing them into one field is the most common reason a triage process stops being trusted, because everything ends up at the top of the scale.

How often should bug triage run, and who needs to be there?

A short recurring pass over everything raised since the last one: daily for a live consumer product, twice a week for slower release cycles. Three roles are usually enough to decide: someone from support who can speak to customer impact, a triage lead who owns severity and priority, and an engineering lead who knows which team owns the code. Anything critical or production down should not wait for the meeting, which is why this chart escalates it immediately to an incident instead of queuing it.

What should happen to a bug that cannot be reproduced?

Close it, but only after an explicit loop. Ask once for the missing detail (build, environment, exact steps, a screen recording), chase within a stated waiting period, then close as cannot reproduce with the reason recorded and an open invitation to reopen if it recurs. This template draws that loop as a decision in the Reporter lane rather than leaving it to individual judgement, because unreproducible reports left permanently open are what turn a backlog into a list nobody reads.