Find and analyze your web frontend errors faster

Besides out-of-the-box error count charting for Dynatrace RUM in version 1.206, you can now also leverage granular alerting for individual errors, improved RUM UI flows during error analysis, and extended error information.

In a world of accelerating deployment cycles, understanding and fixing web front-end errors quickly can make or break your business. For example, developers know that a JavaScript error can ruin the user experience of your web application, so you want to find such errors quickly, analyze them, and ensure that they don’t occur again. Dynatrace Real User Monitoring (RUM) allows you to be proactive, reduce the number of front-end errors, and massively improve user experience.

Whether you check errors based on Davis®-reported problem alerts that you receive or are proactively exploring them in the Dynatrace web UI, your problem analysis should be based on an intuitive workflow that is consistent and explicit. To provide you with such a solution, we’ve further enhanced Dynatrace Real User Monitoring.

In August, as a first step, we announced extended Davis AI awareness of HTTP and custom errors with automatic monitoring of your JavaScript, HTTP, and custom errors. Now, with Dynatrace version 1.206, we also enable you to alert on individual HTTP and custom errors . Additionally, we’ve made error counts available consistently across the product and aided charting of error counts per type on your dashboards. We’ve improved the RUM web UI with additional links and flows to switch between Dynatrace entities, better labels and names for consistency, and extended error information.

Catch errors faster, create tailored front-end error alerts with Davis, and more

Most monitoring solutions available today try to distinguish themselves by providing you with “the best” dashboards, lists, filters, or information to help you find and analyze your front-end errors. While all these elements are certainly important, simply crossing them off a “must-have” list isn’t enough! At Dynatrace, we believe that a truly valuable solution automatically detects the front-end errors that matter to you and provides guidance and comprehensive explanations as to where and why they occurred. Let’s look at two concrete scenarios to illustrate this:     

• As an application owner, you frequently need to report on and improve the error counts of your applications. But you aren’t only interested in error counts per application; you’re probably more focused on ensuring that a specific geolocation or user group doesn’t encounter any errors. Now, using Dynatrace error count metrics, you can tailor the Dynatrace Davis AI to only alert you of errors that matter to you and track those errors over time to optimize your application.
• As a developer, part of your regular performance-improvement routine likely includes exploring and catching errors. For example, as you go through our aggregated waterfall charts to analyze user action performance, you can now see errors from the edge to the core so that you can immediately fix them.

With other new improvements, you can:

• Run better-informed error analysis by accessing the summary of all occurrences
• Capture every failed image and every error page using extended error information
• Analyze the error type you’re most interested in using the simplified error type filter

Get Dynatrace Davis alerts on your error count metrics

We’re excited to announce that with Dynatrace version 1.206, we now provide error counts in the Multidimensional analysis for RUM, which you can now use with calculated metrics. So now you can create your own HTTP or custom error counts for a specific error and use them to set up Davis alerting.

For example, you can make sure that your employees have the required permissions to access certain resources in your internal web application by setting up alerts for HTTP 403 errors (see the image below). Or you can answer questions like “How many of my loyalty customers in Japan run into unavailable resources” by setting up HTTP 404 error alerts that leverage session and action properties to segment your traffic.

Note that we’re working on providing you with the ability to create custom counts and alerts for JavaScript errors too!

Easily visualize error counts per type by pinning custom charts to your dashboard

Besides making error counts available for calculated metrics, we’ve also provided some out-of-the-box application-level error counts that you can use in custom charting. We’ve made it easy for you to pick and chart the correct time series. Simply use the two-click approach shown in the screenshots below to pin error counts per type onto your dashboards.

It’s as simple as selecting Create custom chart on the Multidimensional analysis page for errors and then selecting Pin to dashboard on the custom chart. If you need to change the default settings, you can adjust them on the custom chart.

See errors from the edge to the core

At Dynatrace, we’re convinced that automation isn’t just a matter of problem detection but should also be reflected in the user interface and product experience. So we’ve added hints and links at just those places that we believe will aid your error analysis by enabling you to draw the right conclusions and find true insights.   

• Instantly see which user actions and sessions are affected by JavaScript errors

You can now see information for JavaScript errors that was previously only available for HTTP and custom errors. For example, we’ve added the ability to navigate directly from the JavaScript error details page to the affected user actions and user sessions.

• Analyze individual occurrences with full context

This improvement covers the use case where you likely start off by looking into how to improve the performance of a certain user action and then find errors in an aggregated waterfall—now the Errors finding displays a link and guidance per error type to help you further analyze such errors.

These links automatically take you to the individual waterfall instances filtered by the error type you selected (for example, JavaScript errors) on the aggregated waterfall. We now clearly mark the user action instances that are affected by errors. The new Error count column shows the errors per instance so that you can better prioritize which instances to look at first.

Select an instance and select the Errors finding to see the individual errors.

• Compare user action instances to their aggregates to check “normal” behavior
  

Another improvement that’s very useful for troubleshooting and performance optimization is the ability to jump from a single user action instance in the waterfall chart (the micro level) to aggregated information on the user action details page (the macro level). This is helpful when you want to compare timings and information for an individual user action with aggregate information to check what’s considered normal.

Run better-informed error analysis by accessing the summary of all occurrences

To empower you to run better-informed, high-level error analysis and segmentation, we now show a generic Errors column in all tables and charts. With extended Davis awareness of HTTP and custom errors in RUM, this column now sums up all error occurrences of all error types. You can now use this complete error information when prioritizing errors for analysis and breaking them down by dimensions such as geolocation or user type.

In addition to all application-related pages in the Dynatrace web UI, we’ve also introduced consistent error counts per type and per user action in USQL, which means that you can now use USQL to check for the user actions that have the most JavaScript, HTTP, or custom errors.

Note: If you’re already working with the existing error counts in USQL or the Session export API, please review the details below that explain how the counts will change and what you might need to do.

Capture every failed image and every error page by using extended error information

• Easily catch failed images

Now you can also use extended error information to find failed images. These are indicated with the prefix HTTP <unknown>: in the error name on the Multidimensional analysis page for errors. (Note that error names will be changed to use the prefix “Failed image:…” in a future release.)

In another improvement, we’ve added the HTTP status code on the HTTP error details page so that you don’t need to look these up.

• Capture every single error page

Remember the traditional HTTP 404 error pages that featured cats, dogs, or even Lego figures pulling out an electrical plug? While such pages can be fun, we’ve seen more than a few HTTP error pages that aren’t well designed (think of “Product not found” pages that return an HTTP response code of 200 and are therefore not captured as HTTP errors by Dynatrace RUM).

We’ve now introduced the ability to mark such pages as “true” error pages by using our dtrum JavaScript API. All such pages are then counted as additional HTTP errors and are also highlighted in waterfall charts. The following illustration shows a page that was marked as an error page using the command dtrum.markAsErrorPage(501, "error").

Analyze the error type you’re most interested in using the simplified Error type filter

When you select an error type or user type using the filters in the upper-right corner of the Multidimensional analysis page for errors, your selections are automatically propagated to the Detail analysis below.

Previously, you could filter displayed user actions per error type by selecting, for example, Has JavaScript errors. As the underlying user action could also have other associated error types, this turned out to be confusing. So we’ve changed the logic and the name of the filter. The new Error type filter now does exactly what you’d expect—it only displays the error count of the error type that you select.

Update on error counts in USQL and Session exports

With Dynatrace version 1.204, we’ve introduced the following three new error counts in USQL and Session export for every user action:

• javaScriptErrorCount
• requestErrorCount (already configured for the name change of HTTP errors to Request errors. See the What’s next section below for details)
• customErrorCount
• useraction.failedXHRRequests—Considers only failed XHR calls made in your end user’s browser, which could possibly can be the flip side of your server-side HTTP errors (i.e., httpRequestWithErrors).

These error counts are fully consistent across Dynatrace. Going forward, the existing totalErrorCount for every session will be the sum of these three new error counts.

In turn, we’ll deprecate these existing error counts starting with version 1.212.

• useraction.errorCount—Only includes JavaScript errors.
• useraction.httpRequestsWithErrors—Considers only server-side errors.
• useraction.failedImages—Will be part of the new requestErrorCount.

What should I do now?

If you currently use error counts that will be deprecated in USQL or Session export, please use the following replacements:

• Use javaScriptErrorCount instead of useraction.errorCount.
• Use requestErrorCount instead of useraction.httpRequestsWithErrors and useraction.failedXHRRequests.

What happens after version 1.212?

• USQL and the Session export API result will no longer serve the deprecated counts.
• USQL dashboards using the deprecated counts can’t be displayed, and you’ll need to adapt the underlying queries.
• User session pages will be based on the new counts.

What’s next

Further improvements that we’re already working on include:

• Updated session pages that consider and display the new error counts per user action.
• CSP violations for Chrome browsers—these new errors will be part of a new, more generic error type called “Request errors,” into which HTTP errors and Failed images will be merged.
• Filter and search for individual JavaScript errors.
• The ability to use individual JavaScript errors for calculated metrics, charting, and creating individual error alerts.

Questions?

We’d love to hear your feedback. Please share your feedback with us at Dynatrace Community and feel free to mention any other improvements you believe will help you in better exploring and analyzing your web front-end errors.

Or, if you’re new to Dynatrace, start your free trial now to explore all our performance and troubleshooting capabilities for your front-end applications.