One of the most common questions we get is: “How is Replay (Time-Travel Debugging) different from Session Replay”? In this post, we’ll outline where each excels and why we chose the name Replay.io despite the obvious confusion. 😄
Replay records the actual runtime so you can debug inside the recording itself with print statements and other DevTools. Session Replay records a video with metadata so you can see UI changes.
Time-Travel Debugging is the ability to replay the runtime exactly as it ran before. If a team member records a replay on a Windows laptop in Japan and shares it with you, you will see exactly what they saw.
The browser thinks it is running in Japan on that same Windows laptop, but in reality it is just reading from the recording.
<aside> 👉 The ability to replay the runtime is where Replay.io got its name!
</aside>
Time-Travel Debugging is not a new idea, it is just incredibly difficult to pull off in practice. Computers execute billions of operations a second. If the wrong operation runs out of order, the recording will diverge and fail. For a more in-depth explanation, feel free to read this series on How Replay Works.
Today, the most common workflow is bug reporting. When someone on the team sees a bug, they can record it with the Replay browser and add the replay to the ticket in Linear. This means anyone can debug it without first having to reproduce it.
Because Replay has a fork of Firefox, Chrome, and Node, Replay can also be used to record automated tests in CI. In the future, Replay can also be used to record the backend in production.