Skip to content
Docs

Real user monitoring and session replay

Real user monitoring (RUM) in Orbit Pulse shows how a web front end behaves in real browsers. It covers page views, Core Web Vitals, JavaScript errors, request timings and sessions. Session replay adds a masked recording of a session, but today only Orbit’s own web app can record one. Project administrators set up RUM applications, and every project role can read the results.

Create an application

Section titled “Create an application”

A RUM application receives the data of one front end. Project administrators create applications in the RUM tab. A project can have up to 20.

Setting Meaning
Name Lowercase letters, digits, ., _ and -, 1 to 63 characters. It is also the service name of the application’s spans.
Client token A public token that starts with prum_. It ships in your page and can only send RUM for its own application.
Allowed origins Up to 20 origins, such as https://shop.example.com or https://*.example.com. With none, only your Orbit address may send.
Session sample rate The share of sessions kept, above 0 and up to 1. The default is 1.
Trace requests Adds a W3C trace context to requests so that each one joins its backend trace. The default is on.
Track user Keeps the user you send with a batch on the session. The default is off.

Deleting an application stops its token within 30 seconds. Stored data ages out with the project’s retention.

Send data from your front end

Section titled “Send data from your front end”

A front end posts batches of events to the RUM intake. The client token goes in the query string, because a page cannot always set headers when it unloads.

Terminal
curl -sS -X POST "https://acme.orbit.inortix.com/api/v1/pulse/intake/rum?token=$CLIENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"sentAt": 1761400000000, "session": "s-8f3a1c2d", "env": "production", "version": "2.3.0",
       "events": [
         {"type": "view", "t": 1761399990000, "view": "v1", "seq": 1, "name": "/checkout", "path": "/checkout", "loading": "initial", "lcp": 1100, "cls": 0.02},
         {"type": "error", "t": 1761399995000, "view": "v1", "viewName": "/checkout", "errorType": "TypeError", "message": "x is undefined", "source": "error"}]}'

The reply is 202 with accepted and rejected.

Event type What it carries
view The page view, with its name, path, loading (initial or route) and timings (ttfb, fcp, lcp, inp, cls). Send it again as it progresses with a growing seq.
error errorType, message, stack and a source of error, unhandledrejection, console or network.
request method, url, status, duration and, to join a backend trace, a traceId and spanId.
action The name of a click or other action.

A batch holds at most 256 KB and 500 events. An application can send 20,000 events a minute, then gets 429 with Retry-After. Events older than 24 hours, or more than a minute ahead, are rejected. Pulse corrects a browser clock that is more than a minute off.

Pulse keeps only the path of view names and request URLs, with id-like parts replaced by {id}. It reduces the user agent to browser, system and device type.

Read the results

Section titled “Read the results”

The RUM tab has four parts: an overview, requests, sessions and applications.

  • Overview: page views, sessions, users, errors, a timeline, the slowest pages, and browsers, systems and devices.
  • Web Vitals: each vital is rated good, needs improvement or poor.
  • Requests: latency percentiles per URL, with a link to the slowest backend trace.
  • Sessions: a list, and for each session a timeline of views, requests, errors and clicks.
Vital Good up to Poor above
LCP 2.5 s 4 s
INP 200 ms 500 ms
CLS 0.1 0.25
FCP 1.8 s 3 s
TTFB 800 ms 1.8 s

A query bar uses the shared syntax, for example @lcp:>2.5s.

JavaScript errors join the project’s error groups with the source browser, grouped by type and normalized message. They open in Errors filtered to source:browser. See Errors and Orbit bugs.

A request event with a trace id and span id is stored as a client span of the application’s service. The backend spans it caused then belong to the same trace. These spans count against the daily span quota.

Turn on session replay Planned

Section titled “Turn on session replay ”

Session replay is recorded by Orbit’s own browser script. A recorder for your own front end is not available yet, so today recordings exist only for Orbit’s own web app. The settings and behaviour below are those of that script.

Recording is off for every application until a project administrator turns it on in the application’s Session replay settings.

Setting Meaning
Sample rate The share of kept sessions recorded from the start, 0 to 1. The default is 0.
Record on error A session that is not recorded keeps its last one to two minutes in the browser. When a JavaScript error happens, it sends them and records the rest. The default is off.
Mask text On by default. All page text and attributes such as title, alt, placeholder and aria-label are masked.

Masking happens in the browser, before anything is sent:

  • Form values are always replaced by asterisks.
  • An element marked data-pulse-unmask shows its text even when masking is on.
  • An element marked data-pulse-block is sent as an empty box of the same size.
  • Scripts, inline event handlers, javascript: URLs, and the contents of iframes, canvases and objects are never recorded.

A recording is one page load. The player opens from a session that has a recording, in a sandboxed frame that runs no recorded scripts. It plays at 1× to 8×, skips inactivity, and marks the session’s errors and clicks on the scrubber. Replay next to an error or click starts two seconds before it.

Project administrators can delete a session’s recordings. Its views and events stay. Recordings are kept as long as the project’s retention.

Section titled “Related”