# What is Real User Monitoring (RUM)?

> Real User Monitoring (RUM) captures performance, errors, and behavior from actual users' browsers and mobile devices - page loads, web vitals, session replays - showing what users really experience.

Source: https://openobserve.ai/glossary/what-is-real-user-monitoring/
Published: 2026-07-08
Term: Real User Monitoring (RUM)
Category: Tracing & APM
Related terms: what-is-apm, what-is-observability, what-is-distributed-tracing

---

**Real User Monitoring (RUM)** is frontend observability from the user's side of the wire: a small SDK in your web or mobile app measures what actual users experience - page load performance, interaction responsiveness, JavaScript errors, and user journeys - and streams it to your observability backend. It answers the question backend telemetry never can: *what was it actually like to use the app?*

## Why backend monitoring isn't enough

Your API can serve every request in 80ms while users wait six seconds for a usable page - blocked on JavaScript bundles, third-party tags, slow mobile networks, or layout thrash. Studies of the [frontend experience](/blog/frontend-monitoring-basics/) consistently show most user-perceived latency happens after the backend response. RUM makes that invisible majority measurable.

## What RUM captures

- **Core Web Vitals** - LCP (loading), INP (interactivity), CLS (visual stability), the metrics Google uses to score page experience
- **Timings** - navigation, resource loading, XHR/fetch calls, route changes in SPAs
- **Errors** - JavaScript exceptions with stack traces, failed network calls
- **Context** - browser, device, OS, geography, connection type
- **Sessions** - the sequence of pages and actions; session replay reconstructs it visually
- **Frustration signals** - rage clicks and dead clicks that flag broken UX even without errors

## RUM plus distributed tracing

The most powerful setup connects RUM to backend [distributed tracing](/glossary/what-is-distributed-tracing/): the browser's fetch call carries a trace context header, so one trace runs from the user's click through every backend service. Frontend symptom, backend cause, one view.

## RUM in OpenObserve

OpenObserve includes [frontend monitoring](/frontend-monitoring/) with Core Web Vitals, error tracking, session replay, and [frustration signals](/blog/rum-frustration-signals/) - in the same platform as your logs, metrics, and traces, so frontend and backend telemetry correlate natively instead of living in separate per-seat-priced tools.