Session Replay bridges the gap between user analysis and visually reproducing errors. This guide walks through an example of how developers can leverage Session Replay as a visual aid on documenting post-mortems.

Use RUM to identify how widespread a user issue is

In this example, we noticed that a lot of users were complaining about getting an issue upon clicking the Checkout button. After investigating the RUM frustration signals dashboard, we confirmed in the RUM Explorer that there were nearly 3,000 instances of this error type occurring in just one week:

Use RUM to identify how many instances of an error type occurred in a week

Watch the user issue in a Session Replay

After clicking into a session from the above query, we can watch a Session Replay to see this error occur live, and observe what users did before and after:

Review the user's experience the issue in a Session Replay

Share to a Notebook

To ensure other team members investigating this issue can see this context, we can share this particular Session Replay to a notebook via the share button:

Share the Session Replay video by saving it to a post-mortem notebook

By sending the Session Replay to a notebook, we can add commentary, analyze other telemetry data from this incident, and document our post-mortem.

Note: A template for post-mortem notebooks is available here.

Documenting the post-mortem

After sharing the replay to a notebook, we can begin documenting the investigation.

In Notebooks, add context about behavior in the replay, include appropriate graphs, or tag stakeholders in a comment

We can add context about behavior in the replay, and bring in appropriate graphs to best represent the issue, such as the total number of users affected.

In addition, by adding a comment in Notebooks, we can tag stakeholders who should take a look. In this case, we’ve tagged the product manager responsible for this feature to confirm a fix has been added to the backlog.

Further Reading