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.
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.
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.
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.
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.
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.
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
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.
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:
requestErrorCount(already configured for the name change of HTTP errors to Request errors. See the What’s next section below for details)
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.,
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.httpRequestsWithErrors—Considers only server-side errors.
useraction.failedImages—Will be part of the new
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:
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.
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.
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.