What to do when a bug investigation cannot find the cause

An investigation that ends with an unknown cause is not a failed investigation. A bounded investigation examines the report evidence and the registered source, and when the available facts do not support a cause, the honest result says so. That result still gives you three usable things: a list of unknown facts, the evidence that was checked, and a recommended action. This guide explains how to work with an unknown conclusion instead of discarding it.

An unknown conclusion is a result, not a failure

A review-ready result separates the conclusion, the evidence citations, the unknown facts, a recommended action, and a draft response. The conclusion carries one status: confirmed, likely, possible, or unknown.

The status is calibrated, not decorative. A likely or confirmed conclusion needs repository evidence, and a confirmed conclusion also needs direct visitor-browser evidence. When the evidence does not reach that bar, the result states an unknown cause rather than dressing a guess as a fact. An investigation that reaches its exploration limit still returns a readable result instead of disappearing.

Treat that honesty as information. It tells you the evidence boundary, and it keeps you from releasing a fix for a cause nobody established. Read how to review an AI-generated bug investigation for the complete review checklist that applies to every conclusion status.

Read the unknown facts first

The unknown facts are a section of the result, not a buried caveat. Each important unknown should name the missing fact, why it remains unknown, and the evidence that could resolve it.

Useful unknown facts answer practical questions:

• Does the failure affect every visitor or one account state?
• Does the problem still occur on the current deployment?
• Is the cited source path active for the reported page?
• Which environment or input value differs between the working and failing cases?

Each unknown points at one bounded next check. If the list contains vague entries with no resolving evidence, the review question is different: the result quality, not the conclusion. Reject vague unknowns such as an entry that only says more testing is needed.

Check what evidence the report actually carried

An unknown conclusion often reflects the evidence, not the search. Before you spend anything on a new investigation, compare what the report contained with what the problem needed.

Look at the safe browser evidence that arrived with the report:

• A visitor-approved screenshot, when the visitor included one.
• Bounded console errors and warnings.
• Failed or slow request metadata: a method, a path without query values, a status, a duration, and a time.
• Metadata-only browser state: names, presence, and sizes, never values.

A report with no console items and no request metadata gives an investigation much less to work with than a report that shows POST /api/profile returning 500. Check which evidence categories the website enables, and check whether the visitor statement names the exact action and visible result. The guide to browser evidence for website problems explains what each category can and cannot show.

Decide whether a reinvestigation is worth one credit

A repeat investigation is not free. A reinvestigation consumes one monthly investigation credit, and it uses the current registered source revision rather than the revision the first investigation examined.

Spend the credit when one of these is true:

• The code changed since the first investigation, so the newer revision may contain the fix or a new cause.
• The next report on the same problem carries better evidence, such as a console error or request metadata the first report lacked.
• The first investigation was cut short by a failure rather than an evidence limit. A report preserved as a failed investigation can receive a new investigation when quota and state rules permit it.

Do not spend the credit when nothing changed. The same report, the same evidence, and the same source revision can only return the same unknown. If the evidence is the weak link, improving the next report costs less than repeating the search. Compare the exact monthly limits on the pricing page before you decide.

Improve the next report

The cheapest way out of an unknown conclusion is a better next report.

• Ask the visitor, or any internal tester, to describe the exact action and the visible result. A precise statement narrows the search before any tool runs. Use the website problem report guide.
• Include the browser evidence that matches the failure type. A console error suits a rendering failure. Failed request metadata suits a data failure.
• For a problem that appears and disappears, record the time of each occurrence. The guide to investigating an intermittent website bug covers the harder timing cases.

When a visitor left an optional unverified contact email on the report, you can use your own mail client for a manual follow-up. The product never sends email to that address and never treats it as identity proof, so any follow-up is your decision and your action.

Watch the retention window

Report artifacts are retained for a limited period: seven days on the Free plan and thirty days on the Pro plan. When a result ends in an unknown cause, copy the evidence citations, unknown facts, and your own notes before the window closes. The report lifecycle guide explains the states a report passes through and where each record lives.

Keep a record either way

An unknown conclusion does not block your own investigation or your own notes. You can add notes to the report while you research it, record a human disposition for the result, and write a manual draft response for the visitor without any automated result behind it. Your notes, edits, and decisions stay separate from the immutable result, so the record of what was known, and when, stays honest.

The recommended action in an unknown result can be to collect one missing observation rather than change code. That is a complete next step. For the structure a review-ready result uses, see the illustrative example report.