How to report a bug you could only reproduce once

You saw it. The total was wrong, or the page went blank, or the wrong customer name appeared. You tried again. Everything worked fine.

Now what?

Many testers do not report these bugs at all. They feel unsure. They worry about looking careless. So the bug stays hidden until a customer finds it.

That is the wrong instinct. A bug you saw once is still a bug. It just needs a different kind of report.

Short version

Report it. A partial report beats no report.
Capture evidence in the first 60 seconds, before you try again.
Say honestly how many times it happened out of how many tries.
Write down everything that was unusual about that moment.
Give the developer a theory to test, clearly marked as a guess.

Why these bugs matter more, not less

Bugs that appear rarely are often the most dangerous ones. Here is why.

A bug that happens every time gets found in five minutes by the next person. A bug that happens one time in fifty survives testing, survives review, and reaches production. Then it happens to one customer in fifty — which, at scale, is a lot of people.

Rare bugs are also usually caused by the hardest problems in software: timing, race conditions, caching, memory, and network failures. Those are exactly the problems worth finding early.

So: report it.

The first 60 seconds

The moment you see something strange, stop. Do not click. Do not refresh. Do not try again.

Refreshing the page destroys the evidence, and it is the most common instinct.

Capture these, in this order:

A screenshot of the whole screen, including the browser address bar and any error text.
The browser console. Open developer tools (F12, or Cmd+Option+I on Mac) and screenshot any red errors. If tools were already open, even better.
The network tab. Look for requests that failed, went red, or took a very long time. Save the whole log as a HAR file if you can (right-click → "Save all as HAR").
The exact time. Write down the clock time, including seconds if possible, and your timezone. Developers use this to find your request in the server logs. This one detail solves more intermittent bugs than anything else.
The URL you were on.
A short screen recording, if the problem is still visible.

Only after you have all of that should you try to reproduce it.

A note on tooling: capturing all six of these by hand takes a few minutes, and in a few minutes the page state is often gone. This is exactly the case where a bug reporting tool that records the console, the network log, and the environment continuously — like Crosscheck — is worth having. You press one button and the evidence is already there.

Write down what was different

After you have the evidence, spend two minutes writing down everything unusual about that moment. Do it now, while you remember.

Ask yourself:

How long had the page been open? Sessions and tokens expire.
How many tabs did I have open? State can leak between tabs.
Had I just come back from another page? Back-button bugs are common.
Was I clicking quickly? Double submits cause duplicate records.
Was my internet slow, or did it drop? Half-finished requests cause strange states.
Had a deploy just happened? New code plus an old page in the browser is a classic cause.
Was I using a different account, role, or workspace than usual?
Had I just imported, deleted, or bulk-edited anything?
Was it the first action after logging in? Cold caches behave differently.
What was the data? Very long names, unusual characters, huge numbers, old dates.

You will not know which of these mattered. That is fine. Write them all down. The developer will recognise the important one.

Try to reproduce it properly

Now try again — but systematically, not randomly.

Repeat the exact same steps 5 times. Record how many times it failed.
Change one thing and repeat 5 more times. For example, use a slower network, or click faster, or use a different account.
Keep notes of every attempt.

Even if it never happens again, these notes are valuable. "Failed 1 of 20 attempts" tells the developer this is rare and probably timing-related. "Failed 4 of 5 attempts on Slow 3G" tells them where to look.

Three settings are worth trying deliberately, because they trigger a large share of intermittent bugs:

Network throttling. In DevTools, set the network to "Slow 3G".
Double clicking. Click submit buttons twice, fast.
Two tabs. Open the same record in two tabs and act in both.

The report template

Here is a structure that works for bugs you cannot reproduce reliably.

Title Order total showed $0.00 on Checkout — seen once, cannot reproduce

Frequency Seen 1 time out of approximately 25 attempts.

When it happened 12 Aug 2026, 14:32:10 UTC+5

Environment Chrome 141 · Windows 11 · Staging build 4.7.2 · Account [email protected] (Editor) · Workspace "Acme Demo"

What I was doing

Logged in about 40 minutes earlier and left the tab open

Went to Cart from the Products page

Applied discount code SUMMER20

Clicked Checkout

What I expected Total of $49.99 with the discount applied.

What actually happened Total showed $0.00. The line items were correct. No error was shown.

Evidence

Screenshot: attached

Console: TypeError: Cannot read properties of undefined (reading 'amount') at checkout.js:1:24501

Network: POST /api/cart/totals returned 200 with an empty body

HAR file: attached

What was unusual

Tab had been open ~40 minutes

I had a second tab open with the same cart

Internet connection had dropped briefly a minute earlier

What I tried afterwards

Same steps 5 times: no failure

Same steps on Slow 3G, 5 times: no failure

Two tabs open, 10 times: no failure

My theory (a guess, not confirmed) The totals request returned an empty body, possibly because the session token expired while the page was open. The front end did not handle the empty response and displayed 0.00.

That report is honest, complete, and genuinely useful — even though the tester could not reproduce it.

How to write about uncertainty

Be direct. Do not apologise, and do not overstate.

Good phrases:

"Seen 1 time out of 25 attempts."
"I could not reproduce this again."
"This is a theory, not confirmed."
"I am not sure if this detail is related, but..."

Phrases to avoid:

"It randomly breaks sometimes" — too vague to act on.
"Might be a caching thing?" without evidence — sends people down the wrong path.
"Ignore this if you cannot reproduce it" — this invites the ticket to be closed.

Clear honesty makes your report more credible, not less.

What to ask the team for

An intermittent bug report often needs help from someone with server access. It is reasonable to ask for:

Server logs around your exact timestamp
Error tracking entries (Sentry, Bugsnag, or similar) for that user and time
Whether a deploy happened near that time
Whether other users hit the same error

Very often, the server log for that one minute contains the answer. This is the whole reason you wrote down the exact time.

If it is closed as "cannot reproduce"

Do not take it personally, and do not delete the ticket. Instead:

Ask for the ticket to be kept open with a label like intermittent or needs-more-data.
Add a note each time anyone sees it again, with a new timestamp.
Ask whether the error appears in error tracking in production.

Three reports of the same rare bug, with three timestamps, is usually enough to find it. One report is often not. Keeping the ticket alive is how you get to three.

Frequently asked questions

Should I report a bug I saw once and cannot describe well? Yes. Write what you remember and mark it clearly as low confidence. A weak signal is still a signal.

What if I was the only one who saw it? That happens often, especially with role-specific or data-specific bugs. Your account details and timestamp are what make it findable.

Is an intermittent bug the same as a flaky test? They are related but not the same. A flaky test is an automated test that passes and fails without code changes. An intermittent bug is a real product problem. Both often share the same root cause: timing.

How long should I spend trying to reproduce it? About 15 to 20 minutes of structured attempts. After that, file the report with what you have and move on. Your notes are more valuable than more random clicking.

Will developers be annoyed by a report I cannot reproduce? Good developers strongly prefer a rare bug reported with a timestamp and a console error over a customer complaint three months later. Evidence is what makes the difference.