Build your own observability

Frontend observability with the session behind every error

rrweb records what the browser saw as one timestamped event stream: DOM mutations, clicks, console output, network activity. Build it into your own observability view, and the session behind any error sits one click from the alert, in an open format you own rather than a packaged APM’s closed store.

TypeError: Cannot read properties of undefined

checkout.tsx:214 · 1 session attached

app.acme.com/checkoutsession #8241

Cart total unavailable

▲ TypeError: Cannot read properties of undefined (reading 'total')

  at renderTotal (checkout.tsx:214)

2:41 / 3:44

Public rrweb usage in observability products.

Errors arrive with their session

Exceptions land in the same timestamped event stream as the clicks and DOM changes around them. A stack trace names the function that threw; the session shows what the user was doing when it happened.

  • Console output and uncaught errors are recorded next to the interactions that triggered them.
  • An alert carries a session id and a timestamp, and the replay opens at that exact moment.
  • Error clicks count how many users hit each failure, which settles prioritization arguments.

session #8241 · event stream

console.error · 14:32:07

jump to error →

clicknetworkmutationerror

Watch it while it's happening

Live mode streams a session while it runs, a few seconds behind the user.

  • Confirm an incident is reaching real users before your team pages anyone.
  • Watch checkout sessions on a new release as they come in.
  • Surface the session of the customer your support team has on the phone right now.
Live now3 sessions
user 4f2a…9c · /checkoutLIVE
watching
user 77b1…04 · /onboarding/step-3LIVE
user c0de…7f · /dashboard4m 12s

An audit trail you can replay

A recording is evidence of what the interface displayed and what was done in it. Fraud reviews and compliance audits need exactly that.

  • Custom events mark payouts, permission changes, exports, whatever your domain audits.
  • Masked fields stay masked for everyone, including your own team.
  • Payment iframes record as blanks, and retention and access rules are yours to set.

acct_8123 · admin session · 12:01–12:09

session.start
plan.changed
payout.requested
export.csv

custom event · payout.requested

Replay session context

You control the data

Sessions are typed JSON with millisecond timestamps. The format is documented and open, so nothing you build on it depends on us.

  • Pipe error-adjacent segments into your incident tooling, or attach replay links to alerts.
  • Turn confirmed sessions into replay-backed bug reports with the relevant timestamp attached.
  • Use the same event format to inspect browser automation runs beside production sessions.
{
  "type": 5,
  "data": {
    "tag": "payout.requested",
    "payload": { "amount": 4200, "actor": "admin_31" }
  },
  "timestamp": 1791207471000
}

Start with the recorder. Build the product you need.

rrweb records and replays browser sessions. Plugins add console or network data. Your infrastructure or rrweb Cloud moves, stores, and indexes the events before your product presents them.

01in the browser
REC

rrweb recorder

DOM state, mutations, and user interactions become an open event stream.

02you, Cloud, or Platform
ingest
store
index

Infrastructure

Transport, storage, indexing, queries, and access control.

rrweb Platform provides the containerized backend for deployment in your own cloud.

03owned by you
1:42
+ plugins
console
network

Your product

Replay embedded in your error, support, or customer-facing workflow.

Get rrweb your way

Same open recorder, two backends.

Self-host the pipeline

The MIT-licensed pipeline on your own infrastructure. Recordings never leave your compliance boundary.

Run it on rrweb Cloud

Managed ingest, storage, and replay with the same open recorder. rrweb AI answers questions across sessions, like which errors hit checkout this week. Free tier, no credit card required.

Frequently asked questions

What is frontend observability?

Frontend observability means knowing what actually happened in the user’s browser when something went wrong. Logs, metrics, and traces stop at the network boundary; session recording covers the interface itself, where most user-facing failures are visible.

How does session replay connect errors to behavior?

Errors and interactions land in one timestamped event stream, so every exception links to a session and a moment. The replay opens at that moment with the console output beside it, and the seconds before it show what the user did.

Can session recordings serve as audit trails?

Yes. A recording is evidence of what the interface displayed and what was done in it, which is what fraud investigation and compliance review need. Recordings are personal data, so set retention, access, and masking to match your obligations.

What can session replay not capture?

Closed shadow roots and third-party cross-origin iframes, payment forms above all, render as blanks by browser design. Backend state stays in your logs and traces and joins the session on id and time. Masked fields are captured as placeholders; the real values never leave the browser.

Can I run the complete backend myself?

Yes. rrweb Platform packages the complete backend as containers you deploy in your own cloud. It is sold under a commercial license with maintenance, enterprise support, and SLAs. The recorder and replayer remain MIT-licensed for teams that want to build and operate their own backend.

Why rrweb over a packaged observability or session-replay SaaS?

A hosted product gives you a finished app on its own domain, priced per seat or per session, with recordings in a format only it reads. rrweb gives you the open recorder, event format, and replayer, so you build the session view into your own observability product, join it to your traces and alerts, and keep the data in your storage. Choose the SaaS when a standalone tool is enough; choose rrweb when the session behind an error has to live beside the rest of your telemetry.