> For the complete documentation index, see [llms.txt](https://docs.groundcover.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.groundcover.com/investigate/real-user-monitoring-rum.md).
# Real User Monitoring (RUM)
Monitor web and mobile applications and connect them to your backend, all inside your cloud.
Capture real end-user experiences directly from their browsers and mobile devices, and unify these insights with your backend observability data.
To start sending data, follow the [Connect RUM](/getting-started/installation-and-updating/connect-rum.md) guide for your platform.
### Overview
Real User Monitoring (RUM) extends groundcover’s observability platform to the client side, providing visibility into actual user interactions and front-end performance. It tracks key aspects of your web and mobile applications as experienced by real users, then correlates them with backend metrics, logs, and traces for a full-stack view of your system.
Main benefits of using RUM:
* **Understand the user experience** - capture every interaction, page load, and performance metric from the end-user perspective to pinpoint front-end issues in real time. View sessions with session recording and navigate from an event to the relevant timestamp in the replay.
* **Resolve issues faster** - seamlessly tie front-end events to backend traces and logs in one platform, enabling end-to-end troubleshooting of user journeys.
* **Monitor frontend performance** - track your app performance and get alerted before your users report it to you.
* **Privacy first** - groundcover’s Bring Your Own Cloud (BYOC) model ensures all RUM data stays in your own cloud environment. Sensitive user data never leaves your infrastructure, ensuring privacy and compliance without sacrificing insight.
* **AI-powered investigation** - let groundcover’s [Agent](/automate/agent-mode.md) explain a session or pinpoint the root cause of a front-end exception, turning raw RUM data into an answer in seconds.
### Full-Stack Visibility
One of the core advantages of groundcover RUM is its native integration with backend observability data. Every front-end trace, log, or event captured via RUM is contextualized alongside server-side data:
* **Trace correlation:** Client-side traces (from browser network requests) are automatically correlated with server-side traces captured via OpenTelemetry (OTel) instrumentation. This means when a user triggers an API call, you can see the complete distributed trace that spans the browser and the backend services in a single, unified view. Similarly, users can navigate from a trace to the matching user session in order to understand the user behavior that led to that specific trace.
* **Unified logging:** Front-end log entries and error reports are ingested into the same backend as your server-side logs. In the Data Explorer, you can filter and search across logs from both client and server, using common fields (like timestamp, session ID, or trace ID) to connect events.
* **End-to-end troubleshooting:** With full-stack data in one platform, you can pivot easily between a user’s session replay, the front-end events, and the backend metrics/traces involved. This end-to-end context significantly reduces the time to isolate whether an issue originated in the frontend (browser/UI) or the backend (services/infrastructure), helping teams pinpoint problems faster across the entire stack.
By bridging the gap between the user’s browser and your cloud infrastructure, groundcover’s RUM capability ensures that no part of the user journey is invisible to your monitoring. This holistic view is critical for optimizing user experience and rapidly resolving issues that span multiple layers of your application.
### What RUM collects
#### Web
groundcover RUM collects data from users' browsers through a lightweight JavaScript SDK. Once integrated into your web application, the SDK automatically gathers and sends the following telemetry from each user session:
* **User interactions:** clicks, key presses, and navigation events. By recording which elements users interact with and when, groundcover helps you reconstruct user flows and understand the sequence of actions leading up to any issue or performance problem.
* **Session recording:** a recording of the user's session, to see the behavior that led to specific events. Unlike the other telemetry here, session recording does not start on `init()`. Start it explicitly with [`startReplayRecording()`](/getting-started/installation-and-updating/connect-rum/browser.md#session-replay).
* **Network requests:** every HTTP request the browser makes, such as API calls, captured as a trace. Each client-side request can be linked with its server-side trace, giving you the complete request from the user's click to the backend response.
* **Front-end logs:** client-side log messages, such as `console.log` output, warnings, and errors, stored alongside your server logs.
* **Exceptions:** uncaught JavaScript exceptions and errors, with full stack traces and context such as the browser and URL.
* **Performance metrics:** page load time and Core Web Vitals such as Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, measured for each page view.
* **Custom events:** domain-specific actions or business events you send from your code, such as a completed checkout, with their metadata.
The SDK is built for minimal overhead: sensitive data is masked by default, and CPU-heavy work such as session-replay packing and payload compression runs in a dedicated Web Worker, so your application's main thread stays responsive. See [Connect RUM: Browser](/getting-started/installation-and-updating/connect-rum/browser.md) for setup, configuration, and privacy controls.
#### Mobile
The React Native, Flutter, iOS, and Android SDKs collect:
* **Sessions**, with the device, OS, and app version.
* **Screen views**: each screen the user opens, and the navigation between screens.
* **Taps and gestures**: taps, long presses, swipes, scrolls, and text input. The typed text is never captured.
* **Network requests**, stored as traces and linked to your backend traces.
* **Logs** from your app.
* **Errors and crashes**, including native crashes.
* **Hangs**: ANR on Android and AppHang on iOS.
* **App start**: cold start, warm start, and time to interactive.
* **Frame vitals**: slow and frozen frames per screen.
* **Custom events** you send from your code.
Mobile sessions have no session replay. Each SDK collects a slightly different set of signals. See [What each platform collects](/getting-started/installation-and-updating/connect-rum.md#what-each-platform-collects) and [Connect RUM: Mobile](/getting-started/installation-and-updating/connect-rum/mobile.md).
All RUM data is streamed to your groundcover deployment and stored in your own cloud, where it's indexed like your other telemetry.
### Web and mobile
Every RUM page (**Summary**, **Vitals**, and **Exceptions**) has a platform selector in the header, next to the page name. Select **Mobile** to scope the page to your mobile apps, or **Web** for your web applications. The choice is stored in the URL as `?platform=mobile`, so a link you share opens on the same platform.
Web and mobile have different fields, so switching platform clears your filters and the sessions sort, and closes any open drawer. Each platform keeps its own saved column layout, which loads when you switch to it.
### Explore RUM
* [**Sessions**](/investigate/real-user-monitoring-rum/sessions.md): browse sessions, follow each session's event timeline, replay web sessions, and have the Agent explain a session.
* [**Exceptions**](/investigate/real-user-monitoring-rum/exceptions.md): triage front-end errors, mobile crashes, and hangs, with stack traces and AI root-cause analysis.
* [**Vitals**](/investigate/real-user-monitoring-rum/vitals.md): Web Vitals for your pages, and stability, app start, and rendering health for your mobile apps.
* [**Querying RUM data**](/investigate/real-user-monitoring-rum/querying.md): fields, gcQL examples, monitors, and the API.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.groundcover.com/investigate/real-user-monitoring-rum.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
