What is Heisenbug?

A heisenbug is a software defect that seems to change its behavior or disappear when you attempt to observe or debug it, named, with a nod to the Heisenberg uncertainty principle, because the act of measurement alters the result.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

Heisenbugs are a notorious category of hard-to-reproduce defects. The classic symptom: a bug occurs in production or normal runs, but the moment you add logging, attach a debugger, or run in a slower or instrumented mode, it vanishes, only to return when you stop looking. The reason is usually that the bug depends on timing, ordering, or uninitialized state, and the act of observing changes that timing.

Common causes include race conditions and concurrency issues (debugging slows things down and hides the race), uninitialized memory or variables (debug builds may zero memory that release builds leave with garbage), and optimization differences between debug and release builds. Because adding observation changes the conditions, the normal debug-and-reproduce loop breaks down.

Strategies to catch heisenbugs lean on low-impact observation and reasoning: lightweight logging that does not alter timing, capturing state without pausing, stress and concurrency testing to make the underlying race more frequent, code review and reasoning about thread safety and initialization, and tools like thread/memory sanitizers. The deeper point for testers is that some of the worst bugs resist direct observation, so finding them requires indirect evidence and an understanding of timing, concurrency, and state.

WHY IT MATTERS

Why interviewers ask about this.

The heisenbug is a memorable concept that signals real debugging depth. Explaining why a bug can vanish under observation (timing, concurrency, uninitialized state) and how to catch it (low-impact logging, stress/concurrency testing, sanitizers) shows you understand the hardest end of defect investigation.

EXAMPLE

Example scenario.

A crash happens occasionally in production, but never when a developer runs the app under a debugger. It is a heisenbug: a race condition that the debugger's slower timing hides. The team reproduces it by stress-testing concurrency and adding a thread sanitizer, which surfaces the data race that direct debugging could not.

TIP

Interview tip.

Define a heisenbug as a defect that changes or disappears when you try to observe it, typically caused by timing, concurrency, or uninitialized state. Explain why observation alters the outcome, and give strategies: low-impact logging, stress/concurrency testing to amplify the race, and tools like thread or memory sanitizers.

FAQ

Frequently asked questions.

Why does a heisenbug disappear when you debug it?

Because the bug depends on timing, ordering, or uninitialized state, and observing it changes those conditions. Adding logging or a debugger slows execution and alters timing (hiding a race condition), and debug builds may initialize memory that release builds leave with garbage, so the conditions that triggered the bug no longer occur.

How do you catch a heisenbug?

Use low-impact observation that does not alter timing (lightweight logging, capturing state without pausing), run stress and concurrency tests to make the underlying race occur more often, reason about thread safety and initialization through code review, and use tools like thread and memory sanitizers that detect races and uninitialized access.