How I debug a bug I can't reproduce
Most bugs labeled "can't reproduce" aren't random. Something is different — the environment, the data, or the timing — and the bug is actually 100% reproducible once that difference is found.
Here's what I check, in order.
1. Compare the environment before comparing the code.
Same browser? Same data? Same feature flags? Same user role? I've lost hours debugging "the code" when the real difference was a stale cache or a config value nobody mentioned.
2. Ask what changed recently, not what looks wrong.
A bug that appears out of nowhere almost always has a recent cause — a deploy, a data migration, a dependency bump. Git log and the deploy history are often faster than reading the suspect function.
3. Reproduce the state, not the click.
Most "unreproducible" bugs aren't about the sequence of actions — they're about a specific state: a record with a null field, a list with exactly one item, a token that's about to expire. Find the state and the click sequence stops mattering.
4. If I genuinely can't reproduce it, I stop guessing and add logs.
Guessing and shipping a "fix" for a bug I haven't reproduced is how you get a bug that looks fixed and isn't. A few targeted log lines in production beat ten guesses in a code review.
The honest nuance: sometimes the real fix isn't the bug itself — it's making the bug reproducible. A flaky test or a hard-to-trigger edge case is often worth fixing at the reproduction level, not just patching the symptom.
The goal was never to fix it fast. It's to actually understand why it happened — otherwise it comes back with a different symptom.
What's the worst non-reproducible bug you've ever chased?