Lexicon
Real user monitoring (RUM)
Real user monitoring measures what actual users experience: page loads, web vitals, errors, and sessions. How RUM works and how it joins backend traces.
Definition
Real user monitoring, RUM, captures what actual users experience in their browsers and mobile apps: page load performance, interaction responsiveness, errors, and the shape of whole sessions. It is the outermost layer of observability, measuring the only vantage point that ultimately matters.
What it means in observability
Backend telemetry can be green while users suffer, because much of experienced performance happens after your servers respond: script execution, rendering, third party tags, flaky mobile networks. RUM closes that gap with field data, the real distribution of experience across devices, geographies, and connection speeds. It is the complement to synthetic monitoring, which probes from robots on schedules: synthetics answer is it up, RUM answers what is it actually like.
How it works in practice
A lightweight SDK in the browser or mobile app collects performance timings, including Core Web Vitals measures of loading, interactivity, and visual stability, plus JavaScript errors and session context. The powerful move is connecting layers: frontend instrumentation creates spans and propagates trace context into backend requests, so a slow page can be traced through the API calls behind it, front to back in a single trace.
Where it gets hard
RUM data is personal by nature, so collection needs privacy discipline: consent handling, IP and identifier policies, and scrubbing anything sensitive from URLs and error payloads. Volume forces session sampling decisions with the usual coverage tradeoffs. And the client environment is chaos, with extensions, ad blockers, and ancient devices producing noise that takes care to separate from real regressions.
Where Tsuga fits
OpenTelemetry's browser and mobile instrumentation is maturing quickly, and Tsuga ingests it like any other OTLP source: frontend spans join backend traces, and user experience data lands in the same correlated dataset as the services behind it.
Related terms
- Context propagationContext propagation is the OpenTelemetry mechanism that carries trace identifiers and baggage across process boundaries, so that spans created in different services join into a single trace.
- Distributed tracingDistributed tracing is the technique of following a request across service boundaries by recording a connected span for each operation it touches.
- SLOAn SLO, service level objective, is a target for how reliable a service should be, expressed as a measured indicator held over a time window: 99.9 percent of requests succeed over 30 days, or 95 percent of checkouts complete in under two seconds.
- SpanA span is a single timed operation inside a trace: an HTTP request, a database call, a queue publish, or an internal step worth measuring.