--- title: "Sumo Logic apm and rum: product updates and software features to know" page_name: "New capabilities: Sumo Logic expands Real User Monitoring (RUM)" type: "blog" slug: "expands-real-user-monitoring-rum" published_at: "2022-09-13" modified_at: "2025-05-09" url: "https://www.sumologic.com/blog/expands-real-user-monitoring-rum" canonical: "https://www.sumologic.com/blog/expands-real-user-monitoring-rum" markdown_url: "https://www.sumologic.com/blog/expands-real-user-monitoring-rum.md" lang: "en" excerpt: "Sumo Logic expanded its Real User Monitoring (RUM) capabilities to include core web vital metrics, better visualizations and more." taxonomy_blog_category: - "DevOps & IT Operations" --- [ All blogs ](https://www.sumologic.com/blog "blog")[DevOps & IT Operations](https://www.sumologic.com/blog/devops-it-operations) # New capabilities: Sumo Logic expands Real User Monitoring (RUM) [Pawel Brzoska](#blog-author-block-252) September 13, 2022 5 min read [DevOps & IT Operations](https://www.sumologic.com/blog/devops-it-operations) ##### Table of contents Monitoring the digital experience of users is a must-have these days. Ensuring the end clients are satisfied is difficult though. People are not keen to provide feedback; they just change the vendor without explanation. It is, therefore, crucial to build enough observability into a front-end application (a web page or a mobile UI) so it can tell the story of how well the user perceived the interaction within the application. It’s almost exactly one year since we [first announced our initial release of Sumo Logic Real User Monitoring (RUM)](https://www.sumologic.com/blog/full-stack-observability-real-user-monitoring/) which addresses this exact problem. Since then we received good feedback from our first customers seeing enormous value in it, so today we are proud to announce a set of major improvements to this functionality, extending coverage and visibility of our [RUM solution](https://www.sumologic.com/glossary/real-user-monitoring/) in the browser to the following areas: - Core web vital metrics for document loads - Single Page Apps support: monitoring of XHR calls and Route changes - Tracing browser freeze times: Longtask delays metrics - Better visualizations: Geolocation map - Browsers errors are captured and available in log index as well as on dashboards [Take a deep dive](https://youtu.be/V4u3ToGWT84) into Application Performance Monitoring (APM) and Real-User Monitoring (RUM). Our product team shares advancements we made in the product over the past year and roadmap items for the future. ## Core Web Vitals metrics [Core Web Vitals](https://web.dev/vitals/) (CWV) is an initiative by Google that defines web page KPIs. Each of the CWVs represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome. CWV focuses on three aspects of the user experience—loading, interactivity, and visual stability—and includes the following metrics (and their respective thresholds): - [**Largest Contentful Paint (LCP)**](https://web.dev/lcp/): measures *loading* performance. To provide a good user experience, LCP should occur within **2.5 seconds** of when the page first starts loading. - [**First Input Delay (FID)**](https://web.dev/fid/): measures *interactivity*. To provide a good user experience, pages should have a FID of **100 milliseconds** or less. - [**Cumulative Layout Shift (CLS)**](https://web.dev/cls/): measures *visual stability*. To provide a good user experience, pages should maintain a CLS of **0.1.** or less. We capture all 3 CWV KPIs and display them on Overview dashboards for Document Load action types. Also, detailed metrics are available in span metadata for every transaction trace. We have also added [Time to First Byte](https://web.dev/ttfb/) (`browser_time_to_fb`), a new metric that measures the delay between start of the page load and moment when the first byte of the response appears. It helps identify when a web server is too slow to respond to requests. This metric has also been added to the existing Navigation Timings chart: ## Single page apps / XHR support XHR stands for XML HTTP Request and is a form of communication between the browser and the application backend without (re)loading the page. A typical example is where a page needs to update a ticker of a price automatically or after pressing the “update price” button next to it. Pages can generate one or more XHR requests, typically in the form of HTTP Posts, related to various user actions on a page. What we do with this is: - We measure how many XHR requests have been generated - We measure detailed XHR performance timings - We automatically identify the user action that triggered the XHRs - We measure any erroneous HTTP response to XHR POST calls and count them as XHR errors - We allow to drill-down to specific traces that explain full process of loading and execution of each such transaction XHR technique is quite often used in Single Page Apps (apps that load the page once and then provide all interaction and navigation without loading more documents). Therefore having support for XHR is a key enabler to support SPA browser applications. ## Single page apps / Navigation (route change) support Another browsing technique used by Single Page Apps is a special way of handling page navigation (e.g. clicking on links, buttons, etc) called route change. It is basically a way to navigate to a new page/view without the need to load a new document. Every time we open a new tab in Sumo we do a route change (but we are not loading the whole document at the same time). Such actions typically also generate some XHR calls in the background. What we do with this is: - We create a special type of user action called route\_changes with the name of the page that is being opened (i.e. “Route to [https://service.us2.sumologic….](https://service.us2.sumologic.com/ui#/search/)\*”) - We show these actions as 3rd type of action next to document loads and XHR requests - We measure same type of metrics for them as for XHR requests - We allow to drill-down via Entities tab in right side panel to specific traces that explain full process of loading and execution of each such transaction ## Tracing browser freeze times: Longtask delays metrics [Longtasks](https://github.com/w3c/longtasks) indicate the main browser UI thread is locked for extended periods (greater than 50 milliseconds) and block other critical tasks (including user input) from being executed. If that happens for extended time, the user perceives this as a “freezed browser” that affects experience, even if the communication with the backend has completed a long time ago. RUM 2.0 automatically captures these events and: - Displays them as individual spans in individual traces, marking how long the browser was frozen - Aggregates the above data into two metrics: - Longtask delay: average duration of longtask spans - Time in longtasks: total time spent in longtasks per user action/trace ## Geolocation map Overview dashboards on all explore levels now have a new log-based panel showing geographical user activity for a selected entity. Note this shows only activity, not performance, so red indicates more data, not worse performance. ## Browser errors Sometimes browser UI fails and fails in an unhandled way, failing to deliver the transaction and breaking the user experience. That can happen in situations of unhandled [errors](https://developer.mozilla.org/en-US/docs/Web/API/Element/error_event) or [rejections](https://developer.mozilla.org/en-US/docs/Web/API/Window/unhandledrejection_event) or [failed](https://developer.mozilla.org/en-US/docs/Web/API/Element/error_event) resources. Also, developers can design the page to write erroneous messages to the console. All these situations are captured by Sumo Logic browser instrumentation and forwarded to the same RUM source that is configured for trace data, which then forwards the log data to a continuous tier’s `sumologic_rum_errors` log index. Data in the index is query-able using normal log search query. Here’s a sample query and results: The following fields are available to better aggregate and filter the results: - Application - Service - Operation - Action name and type - Url - ErrorType - Geolocation data - User agent - Span and Trace ids Note that errors don’t always have to be connected with user actions, so it is ok to have some of these fields empty. In addition to that we also aggregate that information in as log-query based panels and display on various dashboards: Logs collection is enabled by default, you can disable by setting `collectErrors=false` in RUM script options. This way, front end developers can have full visibility onto the flow and categories of errors generated by various parts of their browser application with contextual drill-down, free-form search and ability to build custom dashboards, which give them ability to shorten the troubleshooting time and pro-activeness in error tracing. Hopefully these new additions will allow you to even better monitor your users performance and ensure a perfect digital experience for them that is a key for successful business growth with any modern market segment. If you are new to this and would like to try it, here’s a [good starting point](https://youtu.be/n-khmblaQN4) as well as more details on [how to get started](https://help.sumologic.com/Traces/Real_User_Monitoring). ### Article Tags - [DevOps & IT Operations](https://www.sumologic.com/blog/devops-it-operations) Pawel Brzoska Group Product Manager Besides sailing and horseback riding, Pawel was always passionate about great user experience. He spent many years working hands-on with the biggest IT organizations in the world, understanding their problems and challenges with digital transformation to help them exceed their customers expectations by building monitoring and observability products that win the market. Pawel joined Sumo in summer 2019 and is busy since then with extending our platform to cover APM/tracing use cases. [](https://www.sumologic.com/feed "RSS Feed")[](https://twitter.com/intent/tweet?text=New%20capabilities%3A%20Sumo%20Logic%20expands%20Real%20User%20Monitoring%20%28RUM%29&url=https%3A%2F%2Fwww.sumologic.com%2Fblog%2Fexpands-real-user-monitoring-rum "X")[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.sumologic.com%2Fblog%2Fexpands-real-user-monitoring-rum "Facebook")[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.sumologic.com%2Fblog%2Fexpands-real-user-monitoring-rum "Linkedin") [Previous blog SOAR Market Guide 2022: What does the Gartner research say?](https://www.sumologic.com/blog/soar-market-guide-2022-what-does-the-gartner-research-say)[Next blog FedRAMP: The journey to cloud secure operations](https://www.sumologic.com/blog/fedramp-authorization-you-should-know) People who read this also enjoyed [ Sumo Logic AWS Region European Sovereign Cloud is now generally available June 2, 2026 ](https://www.sumologic.com/blog/sumo-logic-aws-region-european-sovereign-cloud-generally-available)[ How to secure cloud workloads without building a full-scale SOC April 30, 2026 ](https://www.sumologic.com/blog/secure-cloud-workloads-with-limited-resources)[ Join operator and Query Agent for smarter log analysis April 22, 2026 ](https://www.sumologic.com/blog/using-the-join-operator)[ 92% of security leaders say their SIEM is effective. 51% say it’s exceptional. What’s living in that gap? April 16, 2026 ](https://www.sumologic.com/blog/from-effective-to-exceptional-siem) [AI Instructions](https://www.sumologic.com/ai-instructions.md)