How it works
The RUM browser SDK posts to write-only ingest endpoints. Each kind lands in its own logs stream, created on first write (schema-on-write):| Endpoint | Stream | Captures |
|---|---|---|
POST /api/v1/rum/v1/sessions | rum_sessions | Session start, user, geo, browser, duration. |
POST /api/v1/rum/v1/actions | rum_actions | Views, resource/API calls, Web Vitals. |
POST /api/v1/rum/v1/errors | rum_errors | JavaScript errors with stack frames. |
POST /api/v1/rum/v1/replay | — | Session replay events. |
On a fresh instance the RUM streams don’t exist until the SDK sends its first event — the RUM pages
show an empty state until then, not an error.
Sessions
The Sessions list shows recent sessions (user, country, browser, duration, error count). Open one for its timeline of actions, plus a Related traces panel.Errors
Errors are grouped by fingerprint so a recurring bug is one row with a count and an affected-users tally. Open a group for the message, the stack, and recent sessions that hit it.Source maps
Upload source maps under RUM → Source maps so minified stack frames are symbolicated back to your original files and line numbers in the error detail.Performance
The Performance page charts Core Web Vitals over time — LCP, FID, CLS, TTFB — and an API performance table (per-URLcount, p50, p95, error rate) computed from resource
actions.
Related traces
RUM closes the loop with your backend. When an action carries a W3Ctraceparent, its trace_id
links the session to the spans it triggered. The session detail’s Related traces panel resolves
them — directly when an action’s trace_id matches, or by time-correlation against the session’s
window when it doesn’t — so you can jump from a slow page to the exact backend trace.