What happens after a visitor sends a website report

A website report is not a message that disappears into an inbox. From the moment a visitor presses send to the moment you record a decision, the report moves through a small number of named states. Knowing those states helps you answer three practical questions: is the report stored, did it receive an investigation, and what do you need to review.

This article follows one report through the complete loop on the product contract as it exists today.

The widget sends a problem or a suggestion

The visitor opens the widget on your site and picks one report type: problem or suggestion. The visitor then describes what happened or what they would change. Nothing else is required.

The visitor can optionally add one contact email. That address is unverified, it is not identity proof, and it is stored separately from the report evidence. Only an authorized reader can see it on the report detail page, and the product never sends email to it. You can use it yourself for a manual follow-up.

The visitor also reviews the safe browser evidence the report can include: a screenshot only after a visible action, a preview, and explicit consent, plus bounded console errors and warnings, failed or slow request metadata, and metadata-only browser state. The widget then confirms receipt with a plain message: the report was received. It does not promise a cause, a reply, or a correction.

Every valid report is stored first

Storage does not depend on quota. When the report arrives, it is stored immediately and its state is received. A report and its investigation have separate states, so a stored report is never a lost report.

The safe browser evidence travels with the report. Query values, headers, request and response bodies, and cookie, form, and local-storage values are excluded by a fixed schema, so the stored evidence stays small and safe to review.

Quota decides when an investigation starts

Each month, an account has a fixed number of investigations. The Free plan provides three investigations per month with one active investigation for the account. The Pro plan provides twenty investigations per month with one active investigation for each website. Compare the exact limits on the pricing page.

When quota is available, the eligible report is queued and receives one bounded investigation. When the account has no quota left, the report is not discarded and not silently delayed. Its state becomes stored_without_investigation, and it remains available for a later investigation when quota returns. Because the monthly limit is small, choosing which stored reports earn an investigation first matters. Read how to decide which website reports get an investigation for a practical spending rule.

The investigation reads the registered source

The investigation is bounded and isolated. It reads and searches the registered source repository at the revision recorded when the report entered the queue, so the result describes the code that was deployed, not whatever was pushed later.

The investigation cannot push a commit, run repository scripts, change your website account, or send any response to the visitor. It examines the safe report evidence, registers source citations, and returns one structured result. If the investigation cannot finish safely, the report is preserved with the state investigation_failed, and you can request one new investigation when quota and state rules permit it. A repeat investigation uses the newer current revision and consumes one monthly credit.

The result separates what is known from what is not

A review-ready result contains five parts, and each part has a distinct job:

• A short conclusion with a status: confirmed, likely, possible, or unknown.
• Source-backed evidence citations, each with a stable identifier, a repository revision, a file path and line range when applicable, and a short safe excerpt.
• The important unknown facts, each with a reason it remains unknown and the evidence that could resolve it.
• One recommended action that still requires human approval.
• A draft response in plain visitor language.

The result can honestly state that the cause is unknown. An investigation that reaches its exploration limit without a cause still returns a readable result rather than a silent failure. The example report shows the complete structure. Before you rely on any part of it, read how to review an AI-generated bug investigation.

A human completes the loop

When the result is ready, the report state is ready_for_review and the decision is yours. You can edit and copy the draft response without sending it, because the product does not send the draft to the visitor. You can record a human disposition, such as accepting the result or asking for more investigation. You can archive the report after an explicit confirmation, and its state becomes archived.

Your edits and decisions stay separate from the investigation result itself. The result remains an immutable record of what the investigation found, while your review sits alongside it in the audit history.

One time limit applies at the end: report artifacts are retained for seven days on Free and thirty days on Pro. Review results inside that window, and archive or copy anything you want to keep.

When you are ready to reply to the person who reported the problem, the draft response gives you a starting point. For the full pattern, read how to respond to a website problem report.