The refreshed JS errors page within Browser’s UI went GA yesterday (9/27/18). It removes pain and toil for users by offering deep context and actionability into:
A. the scope and magnitude of an error, “which error is most impactful to my digital business / where should I start?”
B. the granular details to reproduce the error, and identify the line of code responsible, “what’s the root cause?”
Browser customers wanted more depth, context, and actionability when prioritizing and addressing JS errors. As a result, and after a great effort from the Browser engineering team, the refreshed JS errors page goes live today. If you’re new to Browser you can find it by clicking on the “JS errors” tab.
JS errors is a critical part of New Relic Browser. Often, especially after deployments, our customers will watch the JS errors tab to identify spikes in error rate. Our users need both context and actionability when errors occur. As a result, the refreshed JS errors page offers significant depth into understanding “where should we start,” and the details necessary to both reproduce the error locally and identify the line of code where an error was thrown, answering the question “what’s the root cause?”
In short, everything. The page is purpose-built to enable our users a faster and more actionable method when eliminating JS errors. The following is a walkthrough of the UI with additional context into the user, use cases, common challenges, and how the JS errors page adds value…
Use error messages, filters, and groups for quick context into errors
When you discover an error, you need to quickly understand its impact: Is the error occuring on your most widely trafficked browsers? On the devices your customers use the most?
Previously, we grouped errors by stack trace, but now, by default, we group errors by error message. However, you can sort and group based on attributes that are most important to you; for example, you can group by device type, browser, or URI.
For context into the overall impact of an error, use New Relic Browser to filter and facet on the error. Select an attribute from the Group By list, and isolate errors by that particular attribute (for example, error message, device type, error class, request URI, or user agent name). Add a filter to your groups and combine attributes and dimensions to segment errors by frequency of occurrence or based on the attributes most important to your digital business. Groups and filters provide quick and powerful means to gain context into your most critical errors, so you can decide which one to fix first.
We’ve also added two new graphs: one displays the top five errors by error message (also sortable by attribute), and the other shows page loads with errors sorted by browser type. Additionally, Error profiles, which use New Relic’s applied intelligence, identifies what’s unusual about an error or a set of errors.
Use charts to dive deeper into errors
When you select an error to investigate, New Relic Browser charts provide detailed information about error occurrence based on browser and device type and where the error is most common, helping you get a full understanding of the error.
For each error, we capture basic device and browser level attributes to show you why an error might be occurring on one browser or device and not another. Use the request URI to see the exact page where an has error occured and identify and view errors that are common across multiple page groups. Browser displays request URIs based on time window, and they are filterable.
Browser charts show details about error occurrence across browser and device type.
Reproduce errors from event log data, and dig to the root cause with stack traces and sourcemaps
In addition to event logs, use stack traces and sourcemaps to pinpoint the filename, line of code, function, or method that threw the error.
Use the Event Log to examine the steps leading to an error.
Filter and group errors and review error profiles to narrow down the scope of an error.
Use Browser charts to learn about affected browsers and device types and determine the request URI to isolate the error.
Finally, use the Event Log to reproduce the error locally, and use sourcemaps and stack traces to find the exact line of code, method, or function that’s throwing the error.