Sometimes there can be dozens (or hundreds) of errors to navigate, and this would be tedious to navigate one-at-a-time. To address this, we built a pagination control just below the Timeline to quickly show you the scale of problems during the session, and let you navigate them easily.

We started by flipping the sort-order of the Telemetry Timeline to show the error first and enumerated through prior events. This seemed to make sense for most errors, as the events most relevant to the error likely occurred last. We also gave you control to flip the order back.Error timelines get noisy, especially if your application has a lot of Network or Console chatter. So we gave you control to hide event types, which we hope will make it easier for you to discover the root cause faster.Within the timeline, we’ve also expanded the information we provide about Network events, differentiating <code dir="ltr">XmlHttpRequest</code> and <code dir="ltr">Fetch</code> requests. And we parse out query string parameters to make it easier to understand each request.Multiple errors often happen within a single page view. Understanding them often depends on earlier errors. We made it easier to quickly see what the previous error was by including it directly in the Timeline.Sometimes there can be dozens (or hundreds) of errors to navigate, and this would be tedious to navigate one-at-a-time. To address this, we built a pagination control just below the Timeline to quickly show you the scale of problems during the session, and let you navigate them easily.<h3 name="e016">Step 1. Get visibility into JavaScript errors</h3>Real User Monitoring solutions like Dynatrace today can capture all users and all their interactions on a page. They can also capture JavaScript errors, providing an overview of all errors occurring on a web application. With the impact, today’s JavaScript errors have, this insight is mandatory for operating modern web applications. It allows you to see the impact of new app version deployments and if changes to third-party JavaScript libraries are causing issues. In the screenshot below, we can see that the application is massively impacted with ~100 JavaScript errors/min after a new version of the app was deployed.<h3 name="e84f">Step 2. Narrow down the JavaScript error playground</h3>Even better than simply having the JavaScript error count helping us to prioritize which issue to fix first, is automatically obtaining a narrowed down environment for the JavaScript errors. This allows us to immediately determine on exactly which page the error occurs if there is a specific location, or a specific operating system impacted as seen in the example below.<h3 name="9061">Step 3. Make the JavaScript Stack trace humanly readable (Source&nbsp;Maps)</h3>Since we are minifying for better performance, our JavaScript files become unreadable once deployed. Source map files help developers figure out what the original code looked like. To help developers leverage those capabilities for Real User Monitoring (RUM) and fix errors faster, Dynatrace allows you to upload the source map files, automatically generating a human-readable JavaScript file. The below example shows how this looks in the product where step by step we are getting more visibility depending on the availability of Source Maps, minified JavaScript files, or the source file.<h3 name="86c7">Step 4. Reproducing the JavaScript error leveraging the user’s click&nbsp;path</h3>The final step to get to the bottom of a JavaScrpt error is to reproduce the error. This can be tricky and is where Dynatrace user session tracking supports excels. In addition to the specific JavaScript error instance, it allows you to obtain the user journey with the click steps leading up to the error. The screenshot below shows such a journey where, after the first five steps, the user had a JavaScript error.Thank you for reading. I hope you have found this useful.

technologyandthefuture

Technology & The Future

computerscience

Computer Science

We started by flipping the sort-order of the Telemetry Timeline to show the error first and enumerated through prior events. This seemed to make sense for most errors, as the events most relevant to the error likely occurred last. We also gave you control to flip the order back.

Error timelines get noisy, especially if your application has a lot of Network or Console chatter. So we gave you control to hide event types, which we hope will make it easier for you to discover the root cause faster.

Within the timeline, we’ve also expanded the information we provide about Network events, differentiating <code>XmlHttpRequest </code>and <code>Fetch </code>requests. And we parse out query string parameters to make it easier to understand each request.

Multiple errors often happen within a single page view. Understanding them often depends on earlier errors. We made it easier to quickly see what the previous error was by including it directly in the Timeline.

Sometimes there can be dozens (or hundreds) of errors to navigate, and this would be tedious to navigate one-at-a-time. To address this, we built a pagination control just below the Timeline to quickly show you the scale of problems during the session, and let you navigate them easily.

Step 1. Get visibility into JavaScript errors

Real User Monitoring solutions like Dynatrace today can capture all users and all their interactions on a page. They can also capture JavaScript errors, providing an overview of all errors occurring on a web application. With the impact, today’s JavaScript errors have, this insight is mandatory for operating modern web applications. It allows you to see the impact of new app version deployments and if changes to third-party JavaScript libraries are causing issues. In the screenshot below, we can see that the application is massively impacted with ~100 JavaScript errors/min after a new version of the app was deployed.

Step 2. Narrow down the JavaScript error playground

Even better than simply having the JavaScript error count helping us to prioritize which issue to fix first, is automatically obtaining a narrowed down environment for the JavaScript errors. This allows us to immediately determine on exactly which page the error occurs if there is a specific location, or a specific operating system impacted as seen in the example below.

Step 3. Make the JavaScript Stack trace humanly readable (Source Maps)

Since we are minifying for better performance, our JavaScript files become unreadable once deployed. Source map files help developers figure out what the original code looked like. To help developers leverage those capabilities for Real User Monitoring (RUM) and fix errors faster, Dynatrace allows you to upload the source map files, automatically generating a human-readable JavaScript file. The below example shows how this looks in the product where step by step we are getting more visibility depending on the availability of Source Maps, minified JavaScript files, or the source file.

Step 4. Reproducing the JavaScript error leveraging the user’s click path

The final step to get to the bottom of a JavaScrpt error is to reproduce the error. This can be tricky and is where Dynatrace user session tracking supports excels. In addition to the specific JavaScript error instance, it allows you to obtain the user journey with the click steps leading up to the error. The screenshot below shows such a journey where, after the first five steps, the user had a JavaScript error.

Thank you for reading. I hope you have found this useful.

Tracking and Monitoring Errors in JavaScript

Sanjam Singh's ideas are part of this journey:

Related collections

Similar ideas