Frontend Error Tracking: Session Replay and RUM

You ship a new release and check your backend dashboards. Error rates are flat and latency percentiles look completely normal, so you close your laptop assuming the deployment was a success.

An hour later, customer support lights up. Users complain the page won’t load, buttons don’t work, and everything turns blank after logging in. You pull up the server logs, but every single request returns a 200 OK. The backend served the HTML, the JavaScript, and the API responses correctly. The failure actually happened after the response left your infrastructure and entered the user’s browser, leaving your monitoring stack completely blind.

Server-side telemetry tells you everything is fine while the client-side experience silently fails.

Your Prometheus metrics, Grafana dashboards, and distributed traces saw nothing unusual. The W3C Performance Timeline defines the specific browser APIs that make frontend instrumentation possible. Without them, you’re trying to debug an incident without any client-side context.

The Visibility Ceiling

A 200 response tells you nothing about React hydration crashes, third-party scripts blocking the main thread for 800ms, or ad blockers aggressively removing DOM elements your click handlers depend upon. The browser is a hostile environment filled with extensions you didn’t install, hardware you didn’t pick, and networks you don’t control. You deploy to a predictable server, but your code runs in thousands of completely unpredictable client environments.

RUM vs Synthetic: You Need Both

Real User Monitoring collects performance data from real user sessions across every device, network, and location. RUM might show that your P75 LCP sits at 2.1s while the P95 reaches 6.4s, heavily clustered in Southeast Asia on Android Chrome. This gives you exact data from the field. Synthetic monitoring running from a static remote datacenter would never surface that geographical pattern.

Synthetic monitoring runs scripted browser tests from controlled infrastructure to selectively catch regressions between releases. Lighthouse CI in your pipeline flags a 500ms LCP increase before it reaches active users. It acts as an automated safety check against rapid performance degradation.

Session Replay Architecture

The standard approach uses mutation observers (rrweb ). Instead of dragging in heavy video files, you take an initial DOM snapshot and strictly record every subsequent mutation, scroll, and click as incremental events. This takes roughly 50-200KB compressed per minute versus 500KB-2MB for actual video. Because it is natively searchable by DOM state, when a user reports a broken UI element, you can restore the exact DOM state from the moment they clicked. There is no guesswork, and no debating whether the feature works perfectly on a developer’s machine.

Sampling strategy matters. It makes sense to record 100% of sessions where an error occurs and 100% of sessions where a user contacts support. Sample roughly 5-10% of everything else. Storage scales linearly with your session count. Get your sampling right and session replay becomes a high-value debugging tool. Get it wrong and you end up accumulating massive data storage bills for collecting redundant traces.

Privacy is not optional. You logically need to mask all <input> elements by default. For GDPR compliance, masking has to happen securely on the client at recording time, not during later playback. If unmasked personal data hits your ingestion servers, the strict processing already happened under GDPR rules. Text masking keeps the layout fully intact but cleanly replaces sensitive content with safe placeholders. For standard debugging workflows, the exact sequence of clicks matters far more than the specific text the user typed out.

Source Map Management

Generate source maps during your build phase, upload them directly to your error tracking service, and carefully strip them from the deployment artifact. Tagging the exact upload with a git commit SHA ensures that every error links to the specific source code version that generated it. Never serve source maps publicly, since they act as easily accessible copies of your raw application source files.

Teams typically break this setup in the same three ways. Maps randomly fall out of sync with deployed code when an urgent hotfix accidentally skips the upload step. Retention policies eventually expire before anyone actively investigates an issue. Tags mismatch because the string format for release identifiers shifted between deploys. To counter this predictably, make the source map upload a required CI check rather than an optional post-deploy step. If the upload process fails, the deploy should gracefully fail with it.

Error Grouping and Noise Filtering

Default grouping logic buckets errors strictly by exception type and the top stack frame. This breaks completely when the same underlying root cause generates vastly different stack traces in the wild. A null reference trace spanning three separate React components, all caused by one missing API field, shows up as three separate incidents. What looks like three separate incidents is actually one underlying bug.

Custom fingerprinting directly resolves this by grouping payloads according to message patterns, failing network endpoints, or custom error tags. This approach collapses 300 noisy events into a single actionable issue with an accurate occurrence count.

// Global error handler with noise filtering
window.addEventListener('error', (event) => {
  const stack = event.error?.stack || '';

  // Filter browser extension noise
  if (/chrome-extension:|moz-extension:|safari-extension:/.test(stack)) return;

  // Filter known third-party script errors
  if (KNOWN_NOISE_PATTERNS.some(p => p.test(event.message))) return;

  // Filter bot traffic
  if (/bot|crawl|spider/i.test(navigator.userAgent)) return;

  // Send meaningful errors with context
  errorTracker.capture({
    error: event.error,
    url: window.location.href,
    sessionId: getSessionId(),
    traceId: getActiveTraceId(),  // Links to backend distributed trace
  });
});

Core Web Vitals via Field Data

Core Web Vitals measured actively through RUM provide field data that Lighthouse can only roughly approximate in a lab environment. Broad, sweeping totals are generally useless for these metrics. You get real analytical value by breaking the datasets down by specific page path, device hardware class, and geographic network region.

LCP (threshold: 2.5s): This reflects normal server response time added to the load time of your largest visible screen element. Serving primary LCP images with fetchpriority="high" helps immensely. This single HTML attribute change often moves the needle more than most comprehensive, week-long frontend refactoring efforts.

INP (threshold: 200ms): This uniquely captures the absolute worst interaction latency measured during an active session period. Heavy rendering tasks blocking the single main thread are the usual culprit here. Break them up seamlessly using scheduler.yield(). A mature frontend UX engineering team fundamentally treats INP as a primary metric right alongside LCP constraints.

CLS (threshold: 0.1): Layout shifts usually trigger when asynchronously loaded images arrive without physical dimensions, dynamically injected content pushes existing text around, or custom web fonts swap unexpectedly. To reliably prevent this, actively use aspect-ratio or declare explicit width and height properties on every media element. Reserving spatial block space for dynamic content before it fully resolves keeps the page from rearranging itself, ensuring users click exactly what they intended to click.

Correlating Frontend and Backend

Without proper connection constraints, the frontend team says users are reporting errors, while the backend team points out that all their service metrics look explicitly healthy. Both groups are technically correct based on their own dashboards, but neither can find the root cause acting entirely alone.

The standard solution is to reliably inject a trace ID property into every outgoing fetch request payload. Observability tools like Sentry and Datadog RUM perform this automatically when their client SDKs detect a matching backend APM configuration. Moving from the frontend error directly to the backend trace shows exactly which query timed out, which service returned unexpected data, or which middleware rejected the request. It gives you the full picture without forcing you to switch contexts.

If you configure properly source-mapped traces, session replay, and active frontend-backend correlation, a silent hydration crash will correctly surface as a high-priority alert long before the very first customer support ticket even arrives. The frontend serves as the final edge of your distributed application system. Actively bringing it into your observability stack prevents client-side rendering failures from remaining completely invisible.