Key takeaways
- Bug triage turns every incoming bug into one of three outcomes: an owner, a priority, or a close.
- Severity measures technical damage and priority measures business urgency; keeping the two axes separate is what makes triage meetings produce decisions instead of arguments.
- A 5-20 person team runs best on one 30-minute weekly triage meeting plus a daily async pass over new Sentry issues.
- In Jira, keep a custom Severity field separate from built-in Priority, and add In Triage, Triaged, and Won't Fix statuses with a resolution reason.
- Automated bug-fixing output is a proposal, not a resolution: verify root cause and require a green regression test before merge.
Bug triage is the process of reviewing incoming bugs, assigning each a severity and priority, and routing it to an owner, so your team fixes what matters instead of reacting to whatever Sentry screams loudest. This guide gives you the meeting format, a severity/priority matrix, an exact Jira workflow setup, and a cadence that fits a 5-20 person team.
What is bug triage and what does it mean in software testing?
Bug triage is the process of reviewing every incoming bug, assigning it a severity and priority, and making one of three decisions: fix now, defer to a later sprint, or close as not a bug. The output is an ordered queue your team actually works from, not a backlog that grows on its own.
In software testing, triage happens before release: QA files a bug with reproduction steps, and the team ranks it against the current sprint's work. Production triage is different. Sentry issues arrive with stack traces instead of reproduction steps, and the first task is deciding whether the error is a real regression, a known issue, or noise. That judgment call is where most teams stall.
It is also where automation can do damage. Research on LLM-based program repair found models frequently flag bugs in clean code, and repair rates are lower than the damage done to correct programs, producing pseudo-bug-fixing cycles where the same change is added and removed repeatedly (arXiv study on LLM repair limits). Triage discipline exists to prevent exactly that.
What happens in a bug triage meeting and who should attend?
A bug triage meeting is a 30-minute working session where every new issue gets exactly one of three outcomes: an owner, a priority, or a close. Attendees are the tech lead, the assignee (or whoever found the bug), and someone from product. No one else needs to be in the room.
A 30-minute agenda that ends with owners
Run it in three blocks. First 15 minutes: new issues, each one read aloud from the stack trace and assigned with the severity matrix, not by debate. Next 10 minutes: severity disputes and reopened items, decided by the tech lead with a single sentence of reasoning. Last 5 minutes: stale items, anything untouched for two sprints gets closed or reassigned on the spot. Every issue leaves the meeting with a named owner and a target sprint. If an issue needs more than 90 seconds of discussion, it gets a spike ticket and moves on.
Who runs it when you have no QA
With no dedicated QA, the tech lead chairs and each engineer triages their own new issues asynchronously before the meeting, so the session is confirmation, not discovery. Product attends only the first 15 minutes to set priority context, then drops. The rule that keeps it honest: no issue is discussed without a proposed fix or a proposed close.
How does bug triage work in agile sprints?
In an agile sprint, triage runs on three loops. Daily, someone does an async pass over new Sentry issues, tagging each with severity and owner so nothing sits unclassified for more than 24 hours. Once per sprint, the team holds a synchronous triage meeting to review the backlog, kill duplicates, and commit fixes into the current or next sprint.
The third loop is the interrupt rule: a sev-1 regression breaks the sprint immediately, and the assigned engineer drops feature work to root-cause it. Everything else waits for the daily pass.
The async daily pass matters because debugging already consumes a large share of development time. Without a daily classification habit, your sprint board fills with unowned Sentry issues nobody agreed to fix.
How do you build a bug triage matrix for severity and priority?
Severity vs priority: the one distinction that matters
Severity is technical damage; priority is business urgency. A typo on the pricing page is low severity but gets fixed today. A memory leak in an admin export is high severity and can wait a week. Separate the two axes or every discussion in triage becomes an argument instead of a decision.
Worked examples across a Rails/Laravel/FastAPI stack
Score each Sentry issue on both axes, then read the action off the cell. The matrix below is copyable as-is.
| High urgency | Medium urgency | Low urgency | No urgency | |
|---|---|---|---|---|
| High severity | Fix now | Fix now | Schedule this sprint | Backlog |
| Medium severity | Fix now | Schedule | Backlog | Backlog |
| Low severity | Schedule | Backlog | Backlog | Close |
| Cosmetic | Schedule | Backlog | Close | Close |
Three worked examples:
- Checkout returns 500 on submit (Rails controller raising on a nil payment method): high severity, high urgency → fix now, with a regression test in the same pull request.
- N+1 query on the orders index (Laravel, 40 queries per page load): medium severity, low urgency → backlog, revisit if Sentry shows it escalating.
- Typo in a FastAPI error message string: cosmetic, no urgency → close, or fold into whatever branch is already open.
The rule that keeps the matrix honest: an issue moves cells only when new Sentry evidence appears, not when someone gets annoyed.
How do you set up bug triage in Jira step by step?
Custom fields and workflow statuses
Create a custom field called Severity (S1–S4) separate from Jira's built-in Priority, so severity describes user impact and priority describes fix order. Add three workflow statuses: In Triage, Triaged, and Won't Fix. Won't Fix needs a resolution reason so the same Sentry issue does not get reopened as a duplicate next sprint. Wire transitions so only the triage lead can move an issue out of In Triage, which keeps the meeting honest.
A saved JQL filter for the triage meeting
Save this filter and bookmark it: project = ENG AND status = "In Triage" AND "Severity" is not EMPTY AND created >= -14d ORDER BY "Severity" ASC, created ASC. Run it on the projector during triage. The 14-day window keeps long-standing debt visible without drowning new regressions, and sorting by severity means the meeting ends when the S1s and S2s are assigned, not when everyone's time runs out. This matters because deployment velocity outpaces human response capacity, and teams cannot investigate every regression manually without creating operational bottlenecks.
Automation rules that pre-triage Sentry issues
Use Jira Automation to assign every Sentry-derived issue to the current on-call engineer and set Severity to S2 by default. Tag issues with the Sentry fingerprint so duplicates collapse into one ticket. The rule cannot judge root cause, so treat it as routing, not triage.
What are common bug triage mistakes and how do you avoid them?
Five mistakes account for most broken triage processes, and all five are avoidable with a single rule each. First, triaging every issue synchronously: if a Sentry issue interrupts someone mid-task, that person loses context, the fix still waits, and the interruption cost exceeds the fix cost, so batch issues into one short session instead. Second, severity inflation: when every P1 is marked urgent, nothing is, so hold severity to user impact alone and let priority move during the meeting itself. Third, no closure path: an issue marked triaged with no owner and no next action is just a slower rejection, and every triaged bug needs a named owner and a target sprint written down. Fourth, the backlog graveyard: if issues older than two quarters are never closed or explicitly deferred with a reason, the backlog stops being a signal and becomes noise.
Fifth, treating automation output as triaged. Research on LLM repair agents found they can enter a pseudo-bug-fixing cycle, reapplying and reverting the same change (arXiv:2609.10123). An automated pull request is a proposal, not a resolution: verify the root cause, confirm the regression test, and require green checks before merge.
How often should a team run bug triage?
A solo developer should do a daily 10-minute pass over new Sentry issues, keeping the queue near zero. A team of 5-20 engineers gets the best results from one synchronous 30-minute triage meeting per week, plus an async daily triage of new Sentry issues where the on-duty person assigns severity and owner. The weekly meeting then only argues about priority and sprint placement, not the backlog itself.
Signals your cadence is wrong: issues older than two weeks without an owner, the same regression reopened round by round, or engineers skipping the meeting because nothing got decided last time. If triage decisions keep stalling in Jira, tighten your workflow states and automation rules first (Atlassian Jira documentation).
When should you automate bug triage instead of running more meetings?
Three signals say your triage meeting has hit capacity: Sentry issues arrive faster than you close them, Dependabot PRs sit unmerged for weeks, and CI failures on human-opened PRs consume review cycles that should go to feature work. At that point, adding another meeting just moves the backlog; routing the repetitive portion to a tool does not.
Evaluating automated bug-fixing tools against the same matrix
Run every tool through the same three criteria: does it find root cause, is the fix correct, and does a pull request land green. Sentry Seer (sentry.io/product/seer/autofix/) works inside the Sentry issue you are already watching. GitHub Copilot Autofix targets code scanning alerts rather than runtime errors. Tools like bugstack, Codemend, WarpFix, and Cooper&Wright all turn a Sentry issue into a PR, differing in how far each stays with the fix until checks pass. Cooper&Wright files the fix and stays on the PR until it is green, which covers the last criterion; where it is weakest is novel architectural bugs that need a human design decision, not a patch.
Where automation still needs a human
Research on arXiv found LLM repair rates can lag the damage done to previously correct programs, producing pseudo-fix cycles where the same change is added and removed round by round. So keep humans on severity calls, regression-test review, and anything touching auth, billing, or data migrations. Automate the N+1 queries and stack-trace-driven fixes; triage the rest.
FAQ
Can bug triage be done without a QA team?
Yes. Without dedicated QA, the tech lead chairs the meeting and each engineer triages their own new issues asynchronously beforehand, so the session is confirmation rather than discovery. Product joins only the first 15 minutes to set priority context. The rule that keeps it working: no issue gets discussed without a proposed fix or a proposed close on the table.
What is the difference between bug triage and bug tracking?
Bug tracking is the system where bugs live: Jira tickets, Sentry issues, statuses, and history. Bug triage is the decision-making process applied to that queue: reviewing each new issue, assigning severity and priority, and routing it to an owner with a target sprint. Tracking records the outcome; triage produces it. A tracker full of untriaged issues is just a growing list.
Should the product manager attend bug triage meetings?
Yes, but only the first 15 minutes. Product sets priority context, then drops, since the remaining time covers severity disputes and stale items that need technical judgment, not business input. The full attendee list stays small: tech lead, the assignee or whoever found the bug, and someone from product. Anyone else is optional and usually a distraction.
How do you handle duplicate bugs during triage?
Tag issues with the Sentry fingerprint so duplicates collapse into one ticket in Jira, and kill duplicates during the synchronous meeting's backlog review. Add a resolution reason to Won't Fix closures so the same Sentry issue does not resurface as a duplicate next sprint. One ticket, one owner, one target sprint; duplicates just inflate the apparent backlog.
Is bug triage different for production incidents vs test bugs?
Yes. Test bugs arrive with reproduction steps from QA, so triage ranks them against current sprint work. Production issues arrive as Sentry stack traces, so the first task is deciding whether the error is a real regression, a known issue, or noise. A sev-1 production regression also breaks the sprint immediately: the assigned engineer drops feature work to root-cause it.