React error tracking, symbolicated stack traces, and session replay

A minified trace is a checksum, not a location

Your production bundle is minified, tree-shaken and split into hashed chunks. The exception a user hit arrives as t.map is not a function at main.4f2a1c.js:1:88213 — a line in a file no human wrote, in a chunk name that changes next build. You can read that trace all afternoon and learn nothing.

Remetry symbolicates server-side, so what lands in the dashboard is a symbolicated React stack trace rather than a bundle offset. @remetry/cli uploads the source maps for a build from CI, tagged with the same release string you pass to init(). Events carrying that release are mapped back to src/checkout/Summary.tsx:48:21 before grouping, so the fingerprint is computed over the symbolicated stack. Rebuild, reshuffle every chunk hash, and the issue stays the same issue instead of splitting into a new one.

Capture is two-sided, because React fails in two ways. Global error and unhandledrejection handlers catch what escapes into the browser: event handlers, timers, async work, promise rejections nobody awaited. A React error boundary catches what a component throws during render, before the tree unmounts and the evidence goes with it.

Every error carries the session that produced it

Symbolication tells you where the code broke. It does not tell you that the user double-submitted the form, or that the cart was empty because a request 400'd nine seconds earlier. Session replay does.

Recording is rrweb-based — a DOM mutation stream, not video — loaded as a lazy chunk so it stays out of your initial bundle. The default on-error mode keeps a ring buffer in memory and flushes it the moment the first error fires, then keeps recording live. You get the seconds before the crash without uploading every session that ended fine. Inputs are masked by default, and [data-remetry-block] or [data-remetry-mask] takes anything else out of the recording.

From the issue detail screen, "Open replay" plays back the session that threw. Same event, same timeline, no correlating timestamps across two products.

Which deploy made it worse

Every event carries its release, so the Releases screen can diff each deploy against the one immediately before it. Error rate is compared with a two-proportion z-test, normalised for traffic; LCP p75 is compared against an effect-size threshold. Both are gated on sample floors, so a quiet Sunday morning does not get flagged as a regression.

The output is a verdict, not a graph to squint at: errors +245%, LCP p75 +1.2s vs 1.4.1, with a REGRESSION badge on the deploy card. Spikes fan out to Slack, generic webhooks and email, deduplicated across worker replicas — one incident, one ping.

The failing request, in the same dashboard

Most React errors are downstream of a request. The opt-in apiPlugin() patches fetch and XHR and reports every call, excluding its own transport. URLs are normalised server-side — /orders/123 becomes /orders/:id — so you get P75/P95 latency and error rate per endpoint instead of a million unique paths.

When checkout starts throwing, the answer is usually one endpoint's p95 walking off the chart at the same minute. That is one tab away, not one vendor away.