Real User Monitoring
See exactly what your users see. Every click, every error, every slow request — stitched into the same trace as your backend, so you stop guessing where the problem actually is.
- The Place order click
- Opens the failing backend trace
Frontend observability that speaks the same language as the rest of your stack.
One trace, frontend to database
Every browser fetch carries W3C traceparent and baggage, so a user's click stitches into the same trace as your backend services
Replay every session
rrweb-powered session replay with strict masking by default, lazy-loaded so the baseline SDK stays under 15KB gzip
Privacy-first, by default
Text and inputs are masked unless you opt in per element. Trace headers stay same-origin so you never leak context to third parties
Click to query
From one click to the query that failed
A replay from the demo incident. A shopper presses Place order and waits while the request runs through gateway and orders, until a Postgres call gives up waiting for a connection and the shopper sees an error. Pause or scrub the replay at any step.
Replay: on /checkout a shopper presses Place order. The button reads Placing order… for 8.35s, then the page shows “We couldn’t place your order. Please try again.”
Backend trace
504 · 8.35s
webgatewayorders
SELECT orders · timeout exceeded when trying to connect
Session events
- Route change · /checkouthttps://shop.example.com/checkout0:00.0
- Click “Place order”button#place-order0:02.4
- POST /api/orders504 · 8.35s0:02.4
- ApiErrorPOST /api/orders failed: 504 Gateway Timeout0:10.8
End-to-End Trace Correlation
- Every browser fetch and XHR carries W3C traceparent and baggage headers, so the same request shows up in your backend's traces — not in a separate frontend silo
- Jump from a user's click to the slow database query that backed it in a single waterfall, with frontend and backend spans living in the same view
- session.id and user.id propagate to backend logs and traces, so any backend error is one click away from the exact session that produced it
- Its backend trace, one click away
Session Replay With Privacy By Default
- rrweb-powered replay captures the DOM, every interaction, scroll, and route change so you can watch what the user actually did, not just what they reported
- Strict masking is on out of the box — text and inputs are redacted unless you explicitly unmask them per element, and whole regions can be blocked from replay entirely
- The replay engine is lazy-loaded via dynamic import, so the baseline SDK stays under 15KB gzip and the cost only lands when replay actually starts
Frontend Errors and Crashes
- Capture every uncaught error, unhandled promise rejection, failed resource load, and React render crash with full stack traces and component context
- Error-triggered sampling upgrade: even sessions you chose not to sample get exported the moment something breaks, with the surrounding context intact
- Group errors by frequency, browser, route, and user impact — and from any error, jump straight into the session replay or the matching backend trace
- Every session that hit this ApiError
Real User Performance, Not Synthetic Averages
- Capture real page-load timing on every session — documentLoad, documentFetch, and resourceFetch spans backed by the Navigation Timing API, plus an HTTP span for every fetch and XHR call
- SPA route-change spans automatically adopt the fetch and XHR calls that fire during navigation, so you see the true settling time of every page transition
- Surface UX friction with optional rage-click, dead-click, and scroll-depth detection — so you find the moments users get stuck without waiting for a support ticket
Page load /checkout
example- documentLoad 1.24s
- documentFetch /checkout 182ms
- resourceFetch /assets/index.css 122ms
- resourceFetch /assets/index.js 376ms
- resourceFetch /images/pour-over.webp 328ms
Recorded on every session by the RUM SDK, from the Navigation Timing API