How to compare similar website bug reports

To decide whether similar website bug reports describe the same problem, compare the action, visible outcome, safe request metadata, relevant starting conditions, and source revision. Matching wording is not enough. Keep each original report and record why you think the reports are related, what differs, and what evidence would separate them.

A shared symptom is a reason to compare reports, not proof of a shared cause.

Start with the action, not the headline

Two reports that say “Save does nothing” might describe different failures. One visitor may see an error after submitting a profile form. Another may select a disabled control before required fields are complete. The words match, but the actions and outcomes do not.

Rewrite each report as a short observation:

• Where was the visitor?
• What action did they take?
• What did they expect?
• What appeared instead?
• When did it happen, and which version was involved?

Keep the original statement beside your summary. A summary can accidentally remove a detail that later explains the difference. If the action remains unclear, use the guide to reproducing a bug from a vague report before deciding that two reports are duplicates.

Compare a small set of facts

Use the same comparison fields for each report. Mark unavailable information as unknown rather than filling it from another report.

| Comparison | What a match can suggest | What it does not prove | |---|---|---| | Page and ordered action | The visitors reached a similar flow. | The same starting conditions or cause. | | Visible result | The reports describe a similar symptom. | The same failure path. | | Request method, path, and status | The same request may be involved. | Why that request failed. | | Request duration and occurrence time | A timing pattern may deserve a check. | That delay caused the symptom. | | Console warning or error | The reports may share a technical lead. | That the message explains the reported problem. | | Registered source revision | Source evidence can be compared at one revision. | That every visitor loaded identical assets. | | Relevant starting conditions | A particular account state or entry path may matter. | That the condition is the cause. |

Use only safe request metadata. Do not paste headers, query values, or request and response bodies into the comparison. Read how to interpret failed and slow requests for the limits of those entries.

For cookies, form fields, and local storage, compare names, presence states, and sizes without collecting values. Describe account conditions in general terms and use synthetic data for reproduction.

Separate a working group from a confirmed duplicate

A temporary group helps you investigate without prematurely closing reports. Give it a narrow description such as “profile save failures with the same request path.” Avoid naming an unproven cause in the group title.

A hypothetical comparison might look like this:

• Report A: Profile save returns HTTP 500 on the registered revision.
• Report B: Profile save returns HTTP 500 on that same revision, with similar starting conditions.
• Report C: Profile save returns HTTP 403 after the page has been open for a long time.

A and B are candidates for a shared investigation question. C should stay separate until evidence connects it to them. Even A and B need source review and reproduction before you call their cause the same.

Preserve differences within a group. A mobile-only failure, an older tab, or a different entry path may be the detail that disproves the grouping. The intermittent bug investigation guide explains how to compare conditions one at a time.

Do not infer affected users from report count

Several reports show that several reports were received. They do not establish the number of affected people or the share of visitors who experienced the problem. One person can report more than once, and another affected person may never report.

Keep impact assessment separate from similarity assessment. A report about lost data still deserves careful triage even when it has no apparent duplicate. A frequently reported cosmetic symptom does not automatically outrank it. Use the website issue triage guide to assess harm and whether a workaround exists.

Write down why the grouping remains useful

Keep a short comparison note in your review record:

Reports compared: The report references. Shared observations: The matching action, outcome, request metadata, and revision. Differences: Conditions or evidence that do not match. Current judgment: Related candidates, separate problems, or not enough evidence. Next check: One safe observation or reproduction attempt that could change the judgment.

When new evidence arrives, add a correction instead of silently replacing the earlier reasoning. If a proposed fix addresses one report but not another, split the investigation questions again. Grouping should make evidence easier to inspect, not make unresolved reports disappear.

How to use this method with IssueProbe

IssueProbe stores visitor reports as problems or suggestions and shows safe browser evidence on authorized report detail. An eligible report can receive a bounded, read-only source investigation. Its result separates the conclusion, evidence citations, unknown facts, recommended action, and draft response. The cause can remain unknown.

Compare those observations and citations yourself; this method does not rely on automatic duplicate detection or report merging. You can append an owner note to record related report references and the reason for your judgment without changing the investigation result. Keep private contact information out of the note.

See the illustrative example report for the evidence and conclusion layout. Use the manual investigation record guide when you need to document your own checks. Treat each report's resolution as a separate review decision, even when several reports appear related.