Real User Monitoring

Real User Monitoring (RUM) records web and mobile user experience and connects frontend telemetry with backend observability.

​

How data flows

Both endpoints take the client token of the application. The full list of RUM endpoints is in the RUM API.

​

Data model

Each type of event has its own ordinary Logs stream with a fixed schema. Sessions are derived from the views. Views and sessions are reported again as they change. Each row of the explorer, and each query of the explorer, sees the latest version of a view or a session. In SQL, rum_views_latest and rum_sessions_latest are the streams with only that version (see Query).

​

Overview

Overview is where RUM opens. It is of one application at a time, in one environment or in all of them, over the time range in view. One sentence says how many sessions there were, from how many people, and how many of the sessions had no error; for an app that sends no web vitals it counts the sessions and the people that had no crash instead. Under it are the Core Web Vitals of a browser application, each on the scale it is graded by (good, needs improvement, poor), with the mark at the 75th percentile of its views. A vital opens Performance on it. Then come the most viewed pages (the screens, for an app) with their views, the 75th percentile of each vital, and the share of their views that met an error; a map of where the sessions came from, with the countries that sent the most; the browsers, operating systems, and kinds of device the sessions used; and the elements users were most frustrated by, with what most of the actions on them were. A row of a table, or a bar, opens the explorer on the rows it counts. Open in dashboard in the header of the overview opens the built-in RUM dashboard of the application’s platform, with the application and the environment of the page already chosen. The numbers are counted over every matching row by /api/v1/rum/aggregate. A card whose counting takes too long says so, and the others stay. The country of a session comes from the IP geolocation database, so an application that keeps no place with its events has no map.

​

Errors

Errors lists the errors of an application as issues: the errors that are alike are one issue, with a state (open, investigating, regressed, resolved, or ignored), a team, a person, and a record of when and in which versions it was seen. An issue that was resolved becomes regressed when it comes back in a newer version. Each issue opens in a drawer with its trend, where it happens, its restored stack, its latest sessions, and the people it affected. See RUM errors and issues.

​

Performance

Performance tells how the pages of a browser application do for the people who open them. One sentence says where LCP, INP, and CLS stand at the 75th percentile, each in the colour of its grade, with first contentful paint and the time to first byte beside them. A chart follows the level in front over time, a bar for each level divides the views among good, needs improvement, and poor, and a table lists the pages (or the browsers, countries, or versions) with the level of each. A row opens a drawer that says what the level is made of, which elements set it, and which views were worst. Two more views, Resources and Long tasks, tell what the pages load and what blocks them, and a view of a browser opens on how its page loaded. See RUM performance.

​

Frustration

Frustration tells what frustrates the people who use an application. One sentence says what share of the sessions showed a sign of frustration (rage clicks, dead clicks, and error clicks, or rage taps and error taps in an app), and how many actions showed each sign in how many sessions. A table lists the elements, pages, versions, or browsers by the sessions they touched. A row opens a panel with the sessions touched over time, the signs, the versions and pages, and the newest sessions, each of which opens its replay from five seconds before the sign. See RUM frustration.

​

Analytics

Analytics asks what people do across a session, in three views. Funnel counts the sessions that did a series of pages and actions in order, with the share of them that got through each step, how long they took, and the same by browser, system, device type, version, or country. Paths follows the pages sessions opened after a page, or before it, as columns of the most visited pages. Retention counts the people first seen in a day or a week and the share of them seen again in each period after. The page opens on the last 7 days. See RUM analytics.

​

Alerts

An alert rule can watch a figure of an application: errors, crash-free sessions, the share of sessions with frustration, failed requests, a Core Web Vital at the 75th percentile, and new or regressed issues. The rule reads the figure the way these pages do, so the number it watches is the number the page shows. Narrow it to an environment, a page, and a version. See RUM alerts. Alerts at the end of the row that scopes the overview, errors, performance, and frustration pages counts the incidents going on for the application, and opens its incidents, its rules, and templates that make a rule in one click. See Alert from a page.

​

Investigate with Mole Agent

Investigate with Mole Agent opens Mole Agent with a new chat about what is in view. It stands in the header of the overview, errors, performance, and frustration pages, and where one thing is open: The application is attached to the chat, and the question waits in the message box to be read, changed, and sent. Nothing is sent without a click on send. The button shows to those who hold agent.use. Starting the chat needs streams.query, or sys.telemetry.read in the _sys scope, and records an investigation of the application. Attach an application to any question with @: type its name and pick it under RUM application. A message is refused when the sender cannot read RUM. For the time range of the question, or the last 24 hours when it names none, the model is told:

• the sessions and the people, the share of sessions without an error and without a crash, and the sessions that showed frustration;
• for a browser application, the Core Web Vitals at the 75th percentile with their ratings, and the most viewed pages;
• up to three unresolved issues touching the most sessions, with the versions they were first seen in and came back in;
• the alerts going on for the application, to those who hold alerts.read.

Mole Agent reads RUM with get_rum_overview, list_rum_issues, get_rum_issue, get_rum_vitals, get_rum_frustration, get_rum_view_waterfall, aggregate_rum, get_rum_funnel, get_rum_paths, get_rum_retention, and the tools of sessions, actions, errors, and related traces. They read what the pages read and keep the field masking of the reader. The built-in skill /rum-triage walks them in order: the overview, the issues, the slow or stuck views, the journeys through a flow, the sessions, and the traces of their requests. It cites what it found with links to these pages.

​

Explorer

Open RUM from the main navigation. Explorer lists the sessions, views, actions, errors, resources, and long tasks of real users. Narrow them with a field query, count them over time in the histogram, and open a row in a drawer. A workspace that has no application yet shows how to create one. See RUM explorer. Applications lists the applications, shows their client tokens, and sets what is kept with each event. See RUM applications.

​

Sessions and replay

A session opens from the explorer with its replay, user context, issues, event timeline, and related backend traces. A session that recorded a DOM replay carries the field session.has_replay, so the query session.has_replay = true lists only those sessions. Copy link to this moment in the head of a session copies its address with the replay opened at the moment it is at, and playlists keep the sessions worth watching in a list to go through one after the other. Treat replay as sensitive user data. Apply collection controls in the SDK, avoid recording secrets or personal fields, and use the shortest practical retention.

​

Errors, source maps, and symbols

Errors arrive with their structured stack frames, and are grouped into issues by their type, their message, and the first frames of the application’s own code. Upload browser source maps or mobile symbols from RUM → RUM settings → Source Maps & Symbols. MoleSignal uses uploaded debug artifacts to restore minified, obfuscated, or native frames. Reading artifact metadata requires streams.read; upload and deletion require streams.configure.

​

Related backend traces

When a request carries W3C traceparent, the resource.trace_id of the request links directly to backend spans. A session lists the traces its requests carried. When no request carried a trace ID, session detail searches the session time window for related traces. A slow frontend request can link directly to the corresponding service trace, logs, and metrics while preserving investigation context. The link also works the other way: the head of a trace on Traces offers User session when the trace’s ID was sent by a request of a session, and opens that session.

​

Client IP behind a proxy

RUM events arrive from browsers and devices on the public internet. By default, MoleSignal records the address of the direct connection. When a reverse proxy or CDN sits in front of MoleSignal, every event would carry the address of the proxy and geography would be wrong. Open Settings → Client IP recognition, select a single-value header or a forwarded chain, and list the trusted proxy CIDRs. MoleSignal trusts the header only for connections from those networks. The setting applies to the whole deployment without a restart.

​

Permissions

• rum.write sends RUM events. Application-bound msrum_ tokens grant only this permission for one application.
• streams.query opens the overview, the explorer, the errors, the performance page, the frustration page, the session page, and the list of applications.
• rum.manage sets the state, the team, and the person of an issue. Owners, administrators, and editors have it.
• agent.use shows Investigate with Mole Agent on these pages and lets @ attach an application.
• alerts.read shows Alerts on the overview, errors, performance, and frustration pages, and alerts.manage creates a rule from there. See RUM alerts.
• api_tokens.manage creates, changes, and deletes applications, and shows their client tokens.
• streams.read lists debug-artifact metadata.
• streams.configure uploads or deletes source maps and mobile symbols.