Using Session Replay As A Key Tool In Post-Mortems
Overview
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:
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:
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:
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.
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
Additional helpful documentation, links, and articles:
