How to triage user-reported website issues

Triage is deciding what to work on first when more reports arrive than you can investigate at once. Done well, it is a short, repeatable judgement. Done badly, it becomes a queue sorted by whoever complained most recently or most loudly.

The goal is not to score every report precisely. It is to sort them into a small number of buckets quickly, and to be consistent enough that the ordering survives a busy week.

What three questions decide severity?

Most reports can be ranked with three questions, asked in order.

Is anyone blocked? A blocked visitor cannot complete something they came to do — pay, sign in, submit, download. There is no acceptable alternative path. A visitor who is inconvenienced but can still finish is not blocked, and the difference matters more than how annoying the problem is.

How many people does it affect? A failure on a signup page touches everyone arriving. A failure in an admin export touches a handful. Estimate the share of visitors on the affected path rather than the number of complaints, because reports undercount reality by a wide and unknown margin.

Is the damage reversible? Wrong data displayed is recoverable. Wrong data written — a lost record, a double charge, an email sent to the wrong person — may not be. Irreversible problems outrank cosmetic ones even when far fewer people are affected.

Two more questions break ties: is it getting worse, and did it start after a recent deployment? A problem that is spreading, or that correlates with a change you just shipped, deserves immediate attention because it is likely to have a fast and obvious cause.

What do the severity levels mean?

Use few levels. Four is usually enough, and more than four produces arguments about the boundaries instead of decisions.

• Critical. Money, data, or security is affected, or the core flow is down for most visitors. Work starts now.
• High. A significant flow is blocked for an identifiable group with no workaround. Work starts today.
• Medium. Something is wrong, but a workaround exists or the affected group is small. Scheduled normally.
• Low. Cosmetic, unclear, or a suggestion. Batched.

Write the definitions down and apply them literally. The purpose of a rubric is to make the decision boring — an unwritten scale drifts toward whatever the loudest report was that week.

How do you handle the unreproduced ones?

An unreproduced report is not automatically low severity. A report of a double charge that you cannot yet reproduce still concerns money.

Rank it on the damage it describes, then treat reproduction as the first task rather than as a filter that decides whether it deserves attention. Record what you eliminated so the next attempt starts further along, as described in reproducing a bug from a vague report.

Two failure modes to avoid. Closing unreproduced reports as invalid discards real defects that only appear under conditions you did not think to try. Leaving them open forever creates a backlog nobody reads. A time-boxed attempt with a written outcome — reproduced, not reproduced with these conditions ruled out, or needs one specific follow-up — keeps the queue honest.

Which duplicates matter?

Duplicates are signal, not noise. Several reports describing the same failure raise your estimate of the affected population, which is exactly the input the second triage question needs.

Merge them, keep every reporter attached, and keep each original description. Two people describing the same defect in different words often reveal the shared condition — both were on mobile, both had an unusual character in a field, both arrived from the same link.

Resist merging too eagerly. Two reports with the same visible symptom can have different causes, and merging them hides the second one until much later.

When should a report become a fix?

Not every report should become a code change. Some are questions, some are working-as-intended, and some are requests for different behaviour rather than a defect. Sorting a report into problem, suggestion, or question early avoids investigating something that was never broken. The distinction is covered in bug report or support ticket.

For genuine defects, the investigation should end in one of three honest states: a cause supported by specific source evidence, a cause that is plausible but unproven, or an explicit unknown. Recording an unknown is a real outcome. A guessed cause that nobody can support sends work to the wrong file and leaves the actual defect in production.

What makes triage fast in practice?

Triage speed depends almost entirely on how much context arrives with the report. If every report needs three follow-up questions before you can rank it, triage is not a five-minute pass — it is a week of waiting.

The facts that make ranking immediate are the same ones that make investigation possible: the page path, the exact action, the visible error text, whether a request failed, and which build the visitor was running. With those present, severity is usually obvious on first read.

IssueProbe collects that context when the visitor reports. A visitor submits a problem or a suggestion through a small widget in English, Portuguese, or Spanish; browser-state evidence stays metadata only, with names, presence, and approximate size but never values; and screenshots require a visible capture action, a preview, and explicit consent. Each eligible report can start one isolated, read-only investigation against your repository at the deployed commit, producing a result that cites specific source locations, separates unknown facts, and recommends an action. A human reviews it before anything is sent, and IssueProbe never emails visitors.

Continue with what makes a bug reproducible, or see the example report for how a reviewed result keeps evidence and conclusions separate.