How to investigate an intermittent website bug

An intermittent website bug is a problem that appears only under some conditions. The same action works in one attempt and fails in another, which makes the report easy to dismiss and difficult to reproduce. The practical response is not to repeat the action without a plan. It is to compare a successful attempt with a failed one and find the smallest condition that changed.

Start with facts the browser and visitor can establish: the page, action, time, visible result, failed request metadata, console error, account state, and deployed revision. Do not guess at a cause before those facts point to one.

Confirm that the failures describe one problem

Two visitors can report the same visible symptom for different reasons. A Save button that appears to do nothing could follow a failed request, a validation message outside the viewport, an expired session, or a slow response that eventually succeeds.

Before grouping reports, compare their observable details:

• The exact page and action.
• The visible error text or lack of it.
• The request method, path, status, and duration when a request failed or ran slowly.
• The console message and source location when one appeared.
• The deployed revision associated with the report.

Reports with the same wording but different request paths or revisions may need separate investigations. Reports with different wording but the same failed request and revision may describe one failure.

Compare one success with one failure

A failed attempt alone shows what went wrong. A matched successful attempt helps reveal why it did not always go wrong.

Write both attempts in the same format:

1. Record the starting page and account state.
2. Repeat the same ordered actions.
3. Record the expected and actual result.
4. Note the time and deployed revision.
5. Compare browser errors and request metadata.

Then list every difference you can observe. Useful differences include whether the visitor was signed in, whether the account was new, whether a field was present, whether the page had been open for a long time, whether the visitor arrived through browser back, and whether a request was unusually slow.

Change one condition at a time in the next attempt. If you change the account, browser, data, and network together, a successful reproduction still does not tell you which change mattered.

Look for timing and sequence conditions

Intermittent failures often depend on order rather than a single bad input. Examples include selecting a control before the page finishes loading, sending the same action twice, returning with the browser Back button, or using a page that has remained open across a deployment.

Write sequence details as steps, not summaries. "Submitted the form" hides whether the visitor selected the button once or twice, waited for a response, navigated away, or returned to the page.

Request duration is useful here. A slow request does not prove a timing defect, but it can distinguish a failed attempt from a successful one. Keep only the method, path, status, duration, and time. Headers, query values, and request or response bodies are unnecessary and can contain private data.

Check account and data shape without collecting values

A problem can depend on a structural condition that the visitor does not know is unusual: an optional field is absent, a stored item is much larger than usual, or an account is in a different state.

You can compare those conditions without collecting private values. For cookies, form fields, and local storage, metadata such as the item name, whether it is present, and its size can show a meaningful difference while leaving the value out.

For example, a failed attempt may show that a named field was absent while a successful attempt shows that it was present. That difference is a lead for source review, not proof of the cause. The source still needs to show that the active path handles the two states differently.

Read what browser evidence helps investigate a website problem for the safe evidence categories and their limits.

Match every attempt to the deployed source

An intermittent report can be a version mismatch rather than a random failure. A visitor with an older tab may still be running assets from an earlier deployment. Two reports created minutes apart can therefore describe different source.

Record the full deployed revision with the report. Compare failures and successes only after checking whether they refer to the same revision. If the revision differs, first determine whether the relevant source changed between them.

Do not replace the report revision with whatever is current when the investigation starts. That silently changes the question from "why did this attempt fail?" to "would the current source fail now?" The guide to pinning the deployed commit explains why the mapping must survive later deployments.

Stop with a useful unknown when evidence runs out

An intermittent problem may remain unreproduced after a bounded attempt. Record that outcome precisely:

• Which conditions you tested.
• Which conditions produced success.
• Which evidence appeared only in failed reports.
• Which revisions you compared.
• What one next observation would narrow the problem most.

Do not convert a pattern into a confirmed cause without source evidence. "Failures occurred after a slow request" is an observation. "The slow request caused the failure" is a conclusion that needs a supported chain.

An honest unknown keeps the next investigation focused. A guessed cause sends work to the wrong place and can hide the original problem.

How IssueProbe supports intermittent reports

IssueProbe collects a visitor's problem or suggestion with approved browser evidence from the reporting moment. Failed or slow requests use bounded metadata, console evidence is bounded and redacted, browser state is metadata only, and a screenshot requires a visible action, preview, and explicit consent.

When quota is available, an eligible report can start one isolated, read-only investigation against the registered repository revision recorded for that report. The result separates evidence, conclusion, unknown facts, a recommended action, and a draft response. A likely or confirmed conclusion needs repository evidence, and the result can state that the cause is unknown when the available evidence does not support one. A human reviews the result and draft before external use.

For the complete reproduction method, continue with how to reproduce a bug from a vague report. See the example report for the separation between visitor evidence, source evidence, conclusion, and unknown facts.