Finding the duplicate before you file the ticket

You spend fifteen minutes writing a careful bug report. You attach a screenshot, list the steps, add the browser version. Twenty minutes later a developer closes it: "Duplicate of BUG-4412."

Nothing was wrong with your report. You just did not check first. A two-minute search would have saved the whole thing.

Short version

• A duplicate bug report is a ticket describing a problem that is already filed under a different number.
• Search before you write, not after. Once you have written the report, you will not want to throw it away.
• The four searches that find the most matches are: exact error string, stack trace frame, URL plus element, and symptom synonyms.
• Search the closed and done tickets too. A bug marked "Fixed" that is happening again is a reopen, not a new bug.
• When you find a match, add your evidence to the old ticket instead of filing a new one.
• When you are not sure, file it and link the possible match. An unsure ticket beats a missing one.

---

Why duplicates cost more than they look

A duplicate looks cheap. Someone closes it in ten seconds. But the real cost is spread out:

• Your writing time is gone. Fifteen to twenty minutes per report is normal.
• A triage person read it, opened the linked ticket, compared them, and closed one.
• The bug count is now wrong. If leadership counts open bugs, three duplicates look like three problems.
• Evidence gets split. Your screenshot sits on the closed duplicate. The developer working the real ticket never sees it.

That last one is the expensive part. A developer fixing BUG-4412 might have solved it faster with your console log, but your console log is attached to BUG-4589, which is closed.

Search before you write, not after

The order matters more than the technique. If you write first and search second, one of two things happens. Either you find nothing, which is fine, or you find a match and now have to delete work you just did. People do not delete their own work. They file it anyway and hope.

Make the search the first step. Open the tracker, run two or three queries, then start writing.

Pattern 1: search the exact error string

If the browser console or the API response gave you an error message, that string is the strongest search key you have. It is written by code, so everyone who saw the bug saw the same words.

Copy the error exactly, then trim it to the stable part.

Trim off the parts that change between machines: timestamps, request IDs, user IDs, port numbers, and file hashes like main.4f9a2c.js. Those make an exact match impossible.

Bad search: TypeError: Cannot read properties of undefined (reading 'invoiceId') at InvoiceRow (main.4f9a2c.js:2:88410)

Good search: reading 'invoiceId'

Wrap the phrase in quotes if your tracker supports exact phrase search. In Jira, text ~ "\"reading 'invoiceId'\"" narrows it fast.

Pattern 2: match the stack trace

A stack trace is the list of function calls that led to the error. It is the second-best key, and it works even when the visible error message differs.

Do not search the whole trace. Search one frame — usually the topmost frame that belongs to your own code, not to a library.

TypeError: Cannot read properties of undefined
    at formatCurrency (utils/money.ts:41)
    at InvoiceRow (components/InvoiceRow.tsx:88)
    at renderWithHooks (react-dom.production.min.js:1)

Search formatCurrency or InvoiceRow.tsx. Skip react-dom — that frame appears in hundreds of unrelated errors.

Two reports with the same top application frame are the same bug most of the time, even if one user hit it on the invoice list and another hit it on the customer page. The symptom differs. The cause does not.

Pattern 3: search by URL and element

Not every bug throws an error. Layout problems, wrong text, and broken buttons are silent. For these, search the page path and the thing that broke.

Try these, one at a time:

• The path only: /settings/billing
• The path plus the control: /settings/billing "Save card"
• The control plus the behaviour: "Save card" disabled

Use the path as it appears in the address bar, minus the host and any query string. Search /settings/billing, not https://staging.example.com/settings/billing?tab=cards.

Pattern 4: search the symptom, not your words

This is where most searches fail. You wrote "spinner never stops". The original reporter wrote "page hangs on loading". Same bug, no shared keyword.

Fix this by searching two or three synonyms before you give up. Keep a short list on hand:

Search single words, not sentences. A tracker searching for spinner never stops on billing page will usually return everything containing "page".

A 90-second duplicate check

Do this before you write a word of the report.

1. Copy the error string from the console, if there is one. Trim the unstable parts.
2. Search that string across all statuses, including Done and Closed. Set the date range to the last 90 days.
3. If there is no error, search the URL path instead.
4. Search two symptom synonyms from your list.
5. Sort results by most recently updated and read the top five titles only.
6. Open anything that looks close and compare the steps to reproduce, not the titles.

If you get zero results after all five searches, file the new ticket. You did your part.

What to do when you find a match

Do not close your browser tab and walk away. The existing ticket is probably missing something you have.

If the ticket is open: add a comment with your extra evidence. Say what is new — a second environment, a different browser, a clearer set of steps, a fresh console log. Then bump the priority conversation if your case is worse than the original.

Weak comment: "Same here."

Useful comment: "Also reproduces on staging (https://staging.example.com) with [email protected], Firefox 131 on Windows 11. Original report was Chrome only. Console shows the same reading 'invoiceId' error. Screenshot and HAR attached."

If the ticket is closed as Fixed: this is not a duplicate. This is a regression, which means a bug that was fixed and has come back. File it as a new ticket, link it to the old one with "relates to", and say clearly which release you saw it in. Reopening old tickets loses the fix history, so most teams prefer a new ticket with a link.

If the ticket is closed as Won't Fix or Cannot Reproduce: add your reproduction steps as a comment and ask the triage owner to look again. You may have the missing piece that made it reproducible.

Attaching evidence is much faster when the evidence is collected for you. Crosscheck captures the screenshot, console logs, network requests, and browser details at the moment you report from the page, so pasting a complete set into an existing ticket takes seconds instead of a screen-recording session.

What to do when you are not sure

Sometimes two reports look similar but you cannot tell. Maybe the error is the same but the page is different. Maybe the symptom matches but the version does not.

File the new ticket. Then link it to the suspected match with a "possible duplicate" link and one sentence explaining your doubt: "Same console error as BUG-4412, but that one was on the customer page and this is on the invoice list. Filing separately in case the root cause differs."

Triage can merge two tickets in seconds. Triage cannot recover a bug you never filed. When in doubt, file and link.

Frequently asked questions

How many duplicate bug reports are normal?

Most teams see 5 to 15 percent of incoming tickets closed as duplicates. Above 20 percent usually means the search step is being skipped or the tracker's search is hard to use.

Should I search closed tickets too?

Yes. A closed ticket tells you the bug is known and possibly fixed in a later build. It also tells you whether you are looking at a regression rather than a new problem.

What if my tracker's search is bad?

Add structured fields you can filter on instead of relying on free text. A "Page or module" field and a "Browser" field let you list every open bug for /settings/billing in one filter, with no keyword guessing.

Is it better to reopen the old ticket or file a new one?

If the old ticket was never fixed, comment on it. If it was closed as fixed and the problem is back, file a new ticket and link it. That keeps the fix history of each release clean.

Who should mark a ticket as a duplicate?

The triage owner, not the reporter. Reporters should link the possible match and leave a comment. This avoids closing two different bugs that happen to look alike.