Stop me if this sounds familiar: you see a bug on your site. You want to know what’s going on. You fire up the developer tools, put a breakpoint in the area you think is a problem, and… the error doesn’t occur while it’s being debugged. Probably it’s a timing issue, but I’ve also seen situations where pausing on certain breakpoints will actually cause a browser tab to freeze up. Whatever weirdness you’re dealing with, you can’t get a breakpoint running in the right spot to see the error. These are known colloquially as Heisenbugs, bugs that disappear when measured. Ideally at this point you would add some logging, but if the issue is on production, and you don’t know exactly what needs to be logged, that could delay a fix by an unacceptable amount.

I actually ran into this last night, and decided to test out a tactic I’d heard about in a recent JS Party episode. Did you know that you can use conditional break points to add temporary logging to a live application?

Conditional breakpoints are a browser debugger feature where you set a breakpoint, and specify a condition. The breakpoint only stops the program execution when that condition is truthy. Here’s a video describing the feature in Firefox:

Conditional breakpoints are useful when you’re running through a code path many times during program execution, but you want to stop during a specific run. But they can also be used to solve our heisenbug problem. Because the conditional breakpoint executes the code inside of it in the context of the line we’re trying to break on, we can actually put logging inside the breakpoint.

An example of a console.log inside a breakpoint

That console.log will execute, and because console.log returns false, the breakpoint will never actually stop. It’s a heisenbug-safe version of watching variables when you’re at a breakpoint, and there’s no redeploys required.

Update January 2019: Chrome will soon be building this hack right into the devtools with a new “logpoint” option for breakpoints that formalizes this method. Very cool!