How to record a manual website bug investigation

A useful manual bug investigation records what you observed, what you suspect, what you checked, and what you decided as separate facts. Include the conditions and source revision for each check. When you cannot establish a cause, record the missing fact and the next safe check instead of turning a hypothesis into a conclusion.

This record helps another reviewer continue the work without repeating every attempt. It is also useful when a report has no automated investigation or when an investigation leaves important facts unknown.

Start with the report, not your explanation

Restate the visitor's action, expected result, and observed result before you propose a cause. Keep the original report available so your summary does not replace what the visitor actually said.

Record the page, occurrence time when known, and relevant environment. If you do not know the browser, account conditions, or deployed release, write that explicitly. A missing fact is not a reason to fill the gap with an assumption.

For a vague description, use the steps in reproducing a bug from a vague user report to choose one bounded check.

Separate four kinds of information

Use clear labels in your notes:

• Observation: Something you directly saw or can point to in evidence.
• Hypothesis: An explanation that still needs a check.
• Check: The conditions, action, and outcome of an attempt to test an explanation.
• Decision: What you will do next and why the available evidence supports that choice.

For example, a failed save request is an observation. An expired session causing that failure is a hypothesis until a check supports it. Finding a session-related branch in the source does not establish that the visitor reached that branch.

These are illustrative examples, not IssueProbe customer findings. The distinction applies whether you investigate by hand or review an AI-generated investigation.

Record enough detail to repeat each check

A note that says "tested and works" leaves the next reviewer guessing. State the action, the relevant conditions, and the visible result.

For each check, record:

1. The question you were trying to answer.
2. The environment and release or full source revision you checked.
3. The action you took, using safe test data.
4. The result you observed.
5. What that result supports and what it does not establish.

If a failure does not appear in your test, write "not reproduced under these conditions," not "the report is invalid." The visitor may have used different conditions. Likewise, a successful check on a newer release does not explain a failure on an older one.

Do not change production data merely to complete an investigation note. Use an authorized test environment when a check could write records, send messages, or affect payments.

Use a short investigation note template

Copy this outline for one check at a time:

• Question: What fact am I trying to establish?
• Known evidence: What report details or observations support the question?
• Conditions: Where, when, and on which release did I check?
• Action: What did I do with safe test data?
• Observed result: What actually happened?
• Interpretation: Which explanation does this support or weaken?
• Still unknown: What could change my interpretation?
• Next step: What is the smallest safe check or decision now?

Keep notes short enough to scan, but specific enough to repeat. If a later check changes your view, add a correction that identifies the earlier assumption and the new evidence. Do not silently rewrite the history into a story that makes the answer look obvious from the start.

Keep private values out of the record

Describe relevant conditions without copying passwords, session values, payment details, private form contents, or another person's records. "Signed-in test account with no saved address" can describe a condition without exposing the account's credentials or address.

A screenshot can still contain private information even when the report text does not. Review it before sharing. In IssueProbe, screenshots require a visible visitor action, a preview, and explicit inclusion consent. Browser-state evidence contains only names, presence states, and sizes, never values. Network evidence excludes query values, headers, and request or response bodies.

Manual notes are not a reason to reintroduce the sensitive data that those evidence limits exclude.

Record a decision without overstating the finding

Your decision should follow the evidence strength. You might choose to make a focused change, collect one missing observation, ask a product question, or take no action for now. State why, and keep any unresolved alternative visible.

A proposed change is not a verified fix. Record the verification separately after the change has been reviewed and tested. A visitor-facing draft should describe the behaviour in plain language, omit private source details, and avoid promising a release date you have not approved.

If the cause remains unknown, the guide to working with an unknown investigation conclusion helps turn that uncertainty into a next step.

How to keep manual findings in IssueProbe

IssueProbe preserves a valid report when monthly investigation quota is unavailable. A failed investigation also leaves the report available. An authorized owner can add an owner note before or after a review decision, including on a report with no investigation result. Notes are append-only: add a later note to correct an earlier finding rather than editing or deleting the original.

An owner can also save a manual draft response for a report stored without an investigation or whose investigation failed. That draft does not create an automated result, send email, or consume an investigation credit. For a report with a review-ready result, owner draft revisions and review decisions remain separate from that immutable result.

The dashboard and public API reference provide paths for owner notes and draft responses. Authorized agent actions appear in the human audit history. An owner note records your manual work; it does not turn your hypothesis into a confirmed IssueProbe conclusion.

IssueProbe never sends the draft to the visitor. An optional reporter contact email is unverified and is available only on authorized report detail for manual follow-up. See the illustrative example report to compare your notes with the separate evidence, conclusion, unknown facts, and recommended action in a review-ready result.