Reversible debugging is the ability of the debugger to stop the execution of a program/system after an error/abnormal situation occurs and to perform a "reverse" in time (physical or logical) execution of the debugged program until the error occurs. Despite the fact that experiments in the field of reversible execution began 40 years ago, the topic of reversible debugging became relevant about 10 years ago, when developers of complex, often distributed and heterogeneous, hardware and software systems faced problems of non-deterministic errors and the complexity of their reproduction and localization. Lets define reversible debugging as the ability of the debugger to set a breakpoint in the program and then go back in time until the breakpoint is triggered. There are various ways to implement reversible debugging, for example, program control events record-replay, reverse execution, typical for simulators of hardware and software systems. Reversible debugging is sometimes called bidirectional debugging. Reversible debugging is different from classic cyclic debugging, where you run the program again under debugger control until the error is reproduced and localized. Successful cyclic debugging requires that each run the debugged program behaves the same way, i.e., is deterministic. This is typical for non-interactive single-threaded programs, but for real-time programs, parallel programs, or programs that use asynchronous I/O, re-execution does not always produce the same result. Using the debugger often breaks the cyclograms of parallel programs and real-time programs, so the error becomes masked. Such errors are called Heisenbugs because the act of observation changes the behavior of the system being debugged. This article will review the history and methods of reversible debugging, consider a number of both commercial and free reversible debugging tools.