How to write a useful website problem report

A useful problem report states what the visitor tried, what happened, and where it happened. It does not need a technical diagnosis. A short report with clear context is more useful than a long report with guesses.

Start with the visitor action

Name the action that failed. Use direct words such as save a profile, open an invoice, or submit a form. Add the page where the action occurred. Do not add a password, payment value, or private customer record.

A useful first sentence can follow this form:

I selected Save on the profile page, but the page showed an error and kept the old details.

This sentence gives the owner an action, a location, and an observable result.

State the expected result

Add one sentence about what you expected. This helps the owner separate a product problem from a request for a different feature.

• Problem: The action did not produce its normal result.
• Suggestion: The current result works, but a different result could help.

Use one report for one main issue. Separate reports are easier to review when two actions fail for different reasons.

Add safe context

Useful context can include the page path, the visible error text, the approximate time, and the browser action. Safe browser evidence can also show bounded console errors or failed request metadata.

Never paste a cookie value, an account credential, a payment value, or a private form value. IssueProbe uses metadata only for cookies, forms, and local storage. Read what browser evidence can help before you include extra context.

Keep the report factual

State what you observed. Avoid claims about the cause unless you have direct source evidence. The website owner can compare the report with the active source and record important unknown facts.

See the example report for a complete separation between the visitor report, evidence, conclusion, unknown facts, and recommended action.