How to reproduce and report an intermittent mobile bug
To reproduce an intermittent mobile bug, capture the first failure before you retry. Write down the app build, phone and OS, what the app was doing and the time it failed. Recreate that starting state, then change one condition at a time. Give engineering the number of failures and attempts for each setup, along with the original evidence.
What should you save before tapping Retry?
If the wrong result is still on screen, take a screenshot. Note the date, time and time zone of the failure so a developer can match it to available logs. Write down the last few actions while you remember them, including anything that happened outside the app. A permission prompt, a switch to another app or a network change can be easy to leave out. Apple's Feedback Assistant guide asks for detailed steps, conditions and visual evidence for UI issues. Apple's bug reporting guidance
Record what you know about the starting state. Was this the first launch after an upgrade? Were you already signed in? Was the detail screen still loading when you tapped Back? If you only noticed the problem afterwards, write down when you noticed it and mark the earlier timing as unknown. If you've already restarted, record whether the restart cleared the symptom. That recovery step may give the next tester a way to get back to work.
How do you make two attempts comparable?
Start on the original build and device if you can. Write a setup another tester can recreate, including the test account role and any relevant data or settings. Decide what counts as an attempt and what a failure looks like. If a failure leaves the app in a different state, restore the starting state before counting the next attempt. A test of what happens when you tap Retry on the broken screen belongs on its own row.
Say a tester filters a stock list to show only low-stock items, opens an item and taps Back while its details are loading. The list comes back unfiltered. Each attempt in this fictional example starts with the low-stock filter on and the same item ready to open. An attempt counts as a failure if the filter is off when the list comes back.
| Condition on the same phone and build | Failures / attempts | What the tester saw |
|---|---|---|
| Tap Back while the detail spinner is visible | 3 / 8 | The list returned with the low-stock filter off |
| Wait for details to appear, then tap Back | 0 / 8 | The list returned with the filter still on |
Keep the two rows separate in the ticket. The next tester can see when to tap Back, and the developer has a timing clue to investigate. If the spinner disappears before you can tap, note that you missed the timing. Count only runs where you tapped while it was visible in the first row.
What if the failure only happened once?
Keep the original evidence and record the follow-up attempts separately. For example, “Saw it once after upgrading from build 105 to 112. Could not reproduce in six tries on a fresh install of 112. I haven't retried the upgrade.” The next tester can pick up the upgrade path without repeating the fresh-install checks. Mozilla's bug writing guide asks reporters to state how reliably they can reproduce a problem. Mozilla Bug Writing Guidelines
If a repeat is unlikely, ask the developer which detail would help most the next time it happens. For a failed sync, that might be a timestamp and a request ID if the app exposes one. For a screen that changes too quickly to photograph, use a short screen recording on a test account and note where the failure appears in the clip.
What should an intermittent bug report include?
Keep the first observation and the retries in one issue so the developer can compare them. Link to logs or recordings your team can access and review them for private data before sharing.
Title
[Screen or action] shows [unexpected result] when [observed condition]
First failure
[Date, time and time zone, app build, device and OS]
[Starting state and last actions in order]
Expected result
Actual result
Evidence and where to look
Attempts
[Build and setup] | [Condition] | [Failures / attempts]
[Conditions you couldn't recreate]
Next check
[One condition to compare or one piece of evidence to collect]
When you're ready to file the issue, use the bug report template generator to format the steps and environment, then paste your attempt rows into the same ticket.
Frequently asked questions
Should I report a mobile bug that only happened once?
Yes, if the impact warrants investigation or you have evidence the team can use. Give the build, device, time, last actions and observed result. Say how many retries you made and what changed between the original failure and those retries.
How many times should I try to reproduce an intermittent bug?
There is no universal count. Agree how much time to spend based on the impact and how long each attempt takes. Count failures and attempts separately for each setup, and record any condition you could not recreate.
What does “could not reproduce” mean in a bug report?
It means the tester did not observe the failure in the attempts they ran. State which build, device and starting conditions they used, and keep the original observation and evidence in the issue.