What I mean is coming up with a condition to make as a watch/breakpoint isn't always obvious. Especially with errors that happen "sometimes randomly".

That’s exactly where replay should shine. Stick a breakpoint in your error handler, then rewind when it breaks.

Actually it might be even easier — if your specific error shows up in the console, there's a handy rewind button right beside it :)

If an error causes an exception there is an option to suspend execution when one is thrown.

But typically it will throw an exception _after_ the interesting code happened. For instance it might throw a NullPointerException, but you want to know what set it to null in the first place. With breakpoints you have to suspend on exception, and then add additional breakpoints earlier in the code, and then rerun the code. With rewind you can just step backwards.

The debugger in devtools also has these capabilities.

Can confirm. Use it often both on Chrome and Firefox.

I love the idea of reply, but is it targeting the wrong people to get the post leverage out of it? Print statements generally don't need to be used for debugging if you know how to use a debugger. Which really isn't difficult if you spend maybe half an hour learning it's features.