Navigate back to the homepage
Browse Repo

Effectively Debug Network & Console Errors

Laurena Dehlouz
January 10th, 2020 · 2 min read

Having a website that is slow and full of errors is never a good look. And it’s even more troublesome when your inbox is stacking up to the ceiling with tickets about issues you can’t reproduce.

To effectively troubleshoot issues that happen to your users, you need to see: 1. A perfect representation of their session, 2. How your JS Console and Network Requests behave in response to their actions.

That way, you can get to the root cause of issues and understand their overall impact on your real users very quickly.

With the right set of tools, resolving these issues becomes as easy as pressing play. A good observability platform, that shows you what goes wrong every time an issue occurs, is a superpower.

Session Replay

Typically, when a customer complains, you would have to figure out what was causing the problem by reconstructing the steps you believe that particular user took. But this guessing-game not only takes time, it is ineffective.

Don’t waste your time guessing, or scanning through tons of logs. Simply observe.

The first thing you need is a session replay, this will show you how your users actually did and how they experienced network or console errors.


In the above replay, the user is clearly having a problem: their page is loading very slowing. Now remember, it only takes 2 seconds for someone to lose patience in front of a loading screen, so time here is literally money. But simply replaying the session doesn’t tell me much about what is causing the problem. For that, I need to dig deeper.

Console & Network Replay

Each session replay in OpenReplay shows you the end-user console and the network requests, exactly as they happened, when they happened. Now, in order to understand what is negatively impacting the speed of my software, I simply need to replay the session to see the timing of each browser requests — third-party scripts — media resources in sync with the actions of the user on the website.


Here it becomes obvious: the flags.png image took 268ms to load, much slower than average. This small, un-optimized image was dragging down the performance of the entire page! The Network tab shows each Fetch, XHR, JS, CSS and Media request.

Unique to OpenReplay, you can also analyse each fetch request as they happen during the user session and see the complete detail for each one of them:


And the same goes for console errors: for every issue, each console error is displayed in sync with the video. So when a user reports an issue, simply replaying the session will let you know what the problem was.

In this sense, you can easily troubleshoot issues that are brought back up to you. But you can also monitor issues that have no apparent effect on your end-users’ experience, by analyzing the behavior from the rest of your stack as well. If a problem isn’t obvious from the Console or the Network, then maybe it can be explained by a Back-end issue. OpenReplay connects the information from your front-end with all your other debugging tools, so that you have a full view over every issue.

Long gone are the days spent scratching your head over bugs you can’t reproduce. By having the Network and a Console events alongside a session replay, you never have to guess why bugs are happening.

More articles from OpenReplay Blog

From Log Management to Observability

Strenghten your Backend Visibility by integrating Stackdriver, Bugsnag & Sumo Logic with OpenReplay.

January 3rd, 2020 · 1 min read

Collaborate on Debugging with OpenReplay

Debug quicker and more efficiently by working together with your team in an agile environment.

December 24th, 2019 · 1 min read
© 2021 OpenReplay Blog
Link to $ to $ to $