How to Reproduce Rare Intermittent Bugs

The bug only happens sometimes, which is exactly what makes it maddening. You cannot reproduce it on demand, so you cannot watch it happen or trust that a fix worked. But a bug that appears one time in twenty is not random, it is triggered by a specific combination of timing, device, state, or input you have not pinned down yet. This post is about pinning it down: capturing rich context at every rare occurrence, reading the patterns across many instances, recreating those conditions deliberately, and making progress even when a clean reproduction stays out of reach.

Why intermittent bugs resist you

An intermittent bug is not actually random, it only looks that way because you have not yet identified the conditions that trigger it. Somewhere there is a specific combination of timing, device, state, or input that makes it appear, and your job is to discover that combination. Calling a bug random is really a confession that you are missing data, not a description of the bug's true nature, and reframing it that way is the first step toward actually solving it.

These bugs resist the usual debugging loop because you cannot reproduce them on demand, which means you cannot watch them happen or test a fix reliably. A change that seems to resolve a bug you could only trigger one time in twenty proves nothing, because the bug might simply not have appeared yet. Breaking out of this requires shifting from trying to catch the bug live to capturing enough context whenever it does occur to reconstruct what happened.

Capturing context at the moment

Since you cannot summon the bug, you have to capture everything about the rare moments it does appear. The richer the context attached to each occurrence, the better your chance of spotting the common thread. You want the device and OS, the build version, the exact state the game was in, the recent sequence of actions, and ideally a log of what happened in the seconds before the failure, all captured automatically rather than asked for after the fact.

This is precisely why instrumenting your game to record context automatically beats relying on player memory. A player who hit a rare crash rarely remembers the precise sequence that caused it, but an automatic capture does not forget a single detail. The goal is that every occurrence, however infrequent, arrives with a full snapshot, so a bug that happens once a week still produces useful evidence each time rather than a vague after the fact description you cannot act on.

Finding patterns in the data

Once you have many captured occurrences, the bug stops being random and starts being a dataset. Lay the occurrences side by side and look for what they share. Maybe every crash is on the same OS version, or always follows a particular action, or only happens after the game has been running a long time, or clusters on low memory devices. That shared factor is the trigger you have been hunting, hiding in plain sight across the instances you collected.

Pay attention to what is absent as well as what is present. If a bug never appears on one platform, that platform's difference may hold the clue. Correlate occurrences with timing, like a spike right after a release, which points at a recent change. The more occurrences you can compare, the sharper the pattern, which is why even a low frequency bug becomes solvable once you have collected enough instances of it to compare meaningfully.

Setting it up with Bugnet

Bugnet is well suited to hunting intermittent bugs because it automatically groups occurrences of the same issue and counts them, so a rare bug accumulates evidence over time instead of arriving as scattered one off reports you never connect. Each occurrence carries the device, OS, platform, and build version, and you can attach custom fields for game state and recent actions, building exactly the dataset you need to find the pattern behind the failures.

Because the occurrences are grouped into one issue, you can scan across them in one place and notice that, say, every instance is on a specific OS version or follows the same action. Build version on every report lets you see whether a bug started with a particular release, which narrows the search to what changed. Instead of staring at a single irreproducible report, you work from an aggregated picture that turns a rare bug into a tractable investigation.

Turning patterns into repro steps

Once a pattern emerges, your task is to recreate those exact conditions on purpose. If occurrences cluster on low memory devices, test on a constrained device or artificially pressure memory. If they follow a specific action sequence, perform that sequence deliberately and repeatedly. The pattern from the data becomes a hypothesis, and reproducing the conditions is how you test whether that hypothesis is actually the real trigger or just a coincidence in your sample.

Be willing to exaggerate the suspected conditions to force the bug out. If it seems timing related, slow things down or add load to widen the window. If it seems tied to a rare state, set up that state directly rather than playing until it happens by chance. Once you can trigger the bug reliably by recreating the pattern, you have converted an intermittent ghost into an ordinary bug you can fix and, just as importantly, verify with confidence.

When you still cannot reproduce

Sometimes the pattern is unclear or the bug stays stubbornly elusive, and you have to make progress without a clean reproduction. In that case, add more targeted instrumentation around the suspected area and ship it, so the next occurrences carry even richer evidence. Each release tightens the net, and a bug you cannot reproduce today often becomes obvious once a few more well instrumented occurrences come in from the field with the extra detail you added.

You can also ship a defensive fix that hardens the suspected code path even without a confirmed repro, then watch the occurrence count. If the count drops to zero after the change, the data confirms the fix even though you never caught the bug live. Reproducing rare bugs is ultimately a patience game, and the team that systematically captures context and reads the patterns will solve them while others keep marking them cannot reproduce and moving on.

A bug that only happens sometimes always happens under conditions you have not pinned down yet. Capture context, read the pattern, and it stops being random.