Frontend Observability in Production
A complete guide to frontend observability architecture for engineering teams. Covers real user monitoring, OpenTelemetry browser instrumentation, trace correlation between frontend and backend, and how to capture Core Web Vitals and errors in production.
Introduction#
Backend observability, the practice of instrumenting servers and services with traces, metrics, and logs to understand what is actually happening in production, has been standard practice for years. Distributed tracing, structured logging, and dashboards built on tools such as Prometheus, Grafana, and Jaeger are common infrastructure in most backend teams by now.
The frontend has lagged behind. For a long time, understanding how a web application actually performed for real users meant relying on a narrow set of signals: error reporting tools that captured stack traces, and separate performance monitoring tools that reported aggregate metrics like page load time. These tools rarely spoke to each other, and almost never connected cleanly to what was happening on the backend during the same user session.
Frontend observability is the effort to close that gap, applying the same tracing based approach used on backend systems directly to the browser, so that a single request from a user’s click through to a database query and back can be followed as one connected trace rather than several disconnected data sources.
What Frontend Observability Means#
At its center, frontend observability is the practice of capturing traces, metrics, and logs directly from the browser and treating that browser session as one leg of a larger distributed system, the same way a backend service is treated as one leg of a request that touches several services.
This differs from traditional frontend monitoring in an important way. A typical error tracking tool tells you a JavaScript exception occurred and where in the code it happened. Frontend observability goes further, capturing the full sequence of events leading up to that error, including page loads, user interactions, and network requests along with their timing, connected into a trace that can be correlated with what the backend was doing during that same request.
Why Backend Observability Practices Are Moving to the Browser#
Real user monitoring, commonly shortened to RUM, captures something synthetic testing cannot: the actual experience of real users on real devices and real networks. Synthetic tests run on a schedule from controlled environments, which makes them useful for catching regressions but blind to the long tail of real world conditions users actually encounter, from a slow mobile connection to an older device struggling to execute JavaScript quickly.
The practical motivation for teams adopting this now is troubleshooting speed. Without a connected trace, diagnosing a slow page for a specific user typically means checking frontend error logs, then separately checking backend logs, then trying to line up timestamps by hand to guess which backend request corresponds to which frontend interaction. A correlated trace removes that manual correlation step entirely.
The Role of OpenTelemetry#
OpenTelemetry has become the standard most teams are converging on for frontend observability. It is vendor neutral, meaning instrumentation written against the OpenTelemetry API can be exported to any compatible backend, whether that is Grafana, Elastic, Honeycomb, or a self hosted collector, without rewriting the instrumentation itself if a team switches providers later.
The browser SDK generates spans for page loads, user interactions, and network requests, then exports them to an OpenTelemetry Collector, which can forward that data to whichever observability backend a team has chosen. Because the same standard already governs backend instrumentation at most companies using it, a browser span and a backend span from the same request can be stitched together into a single trace automatically, using shared trace context propagated through request headers.
What Gets Instrumented#
A typical frontend observability setup captures several categories of signal.
Page load performance, including Core Web Vitals such as Largest Contentful Paint and Interaction to Next Paint, gives a direct read on how fast a page actually feels to the person using it.
User interactions, such as clicks, form submissions, and navigation events, are captured as spans, giving visibility into the sequence of actions a user took before an issue occurred.
Network requests, particularly fetch and XMLHttpRequest calls, are automatically instrumented so that a frontend request can be traced through to the backend service that handled it.
JavaScript errors are captured with full context, including the sequence of spans that preceded the error, rather than just an isolated stack trace.
Correlating Frontend and Backend Traces#
The most valuable part of this architecture is trace propagation, the mechanism that lets a single trace span both the browser and the backend. When the browser SDK makes an instrumented network request, it automatically injects a trace context header into that request. If the backend service is also instrumented with OpenTelemetry, it reads that header and continues the same trace rather than starting a new one.
The practical result is a single, connected view: a click in the browser, the network request it triggered, and every backend service that request touched, all visible as one trace rather than several disconnected logs that have to be manually correlated by timestamp.
Building a Basic Browser Instrumentation Setup#
A minimal setup involves configuring a tracer provider, registering automatic instrumentation for page loads and network requests, and exporting spans to a collector.
import { WebTracerProvider } from "@opentelemetry/sdk-trace-web";
import { registerInstrumentations } from "@opentelemetry/instrumentation";
import { DocumentLoadInstrumentation } from "@opentelemetry/instrumentation-document-load";
import { FetchInstrumentation } from "@opentelemetry/instrumentation-fetch";
import { BatchSpanProcessor } from "@opentelemetry/sdk-trace-web";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
const provider = new WebTracerProvider();
provider.addSpanProcessor(
new BatchSpanProcessor(
new OTLPTraceExporter({ url: "https://collector.example.com/v1/traces" })
)
);
provider.register();
registerInstrumentations({
instrumentations: [
new DocumentLoadInstrumentation(),
new FetchInstrumentation(),
],
});This captures page load timing and outgoing fetch requests automatically. Production setups typically add custom spans around critical user flows, such as checkout or search, so teams can measure exactly the interactions that matter most to the business, not just generic page metrics.
Privacy and Performance Considerations#
Frontend telemetry involves data collected directly from user browsers, which raises privacy considerations that backend telemetry generally does not. Personally identifiable information such as email addresses in form fields or sensitive text entered by users should be sanitized before it leaves the browser, typically using a custom processor that redacts sensitive fields before export.
Performance overhead is also worth watching. Instrumentation adds a small amount of work to every page load and interaction, so production setups typically use batch span processors rather than sending each span individually, and apply sampling to reduce volume on high traffic applications rather than capturing every single session in full detail.
Routing telemetry through a collector proxy, rather than sending it directly from the browser to a third party observability backend, is a common pattern. It allows a team to handle CORS headers centrally, apply access control, and filter or transform data before it reaches storage.
Common Pitfalls#
Teams adopting frontend observability for the first time tend to run into a few recurring issues.
Over instrumenting early is common. Capturing every possible interaction from day one produces a large volume of low value data that makes genuinely important signals harder to find. Starting with automatic instrumentation for page loads and network requests, then adding custom spans only around flows that matter, tends to produce a more useful dataset.
Treating session replay as pixel perfect recording rather than a lightweight wireframe view can introduce both a performance cost and a privacy risk, since capturing exact visual detail often means capturing exact user data along with it.
Skipping the collector proxy and sending telemetry directly to a vendor from the browser can create CORS issues, expose API keys client side, and remove the ability to filter or redact data centrally before it leaves the organization’s own infrastructure.
When to Invest in Frontend Observability#
This investment pays off most clearly for teams running production applications where diagnosing user reported issues currently takes real effort, where the frontend and backend are maintained by different teams that need a shared view of what happened during a specific request, or where Core Web Vitals and real user experience data directly affect business metrics such as conversion or search ranking. For a small internal tool with few users and simple architecture, the setup cost is unlikely to be worth it compared to basic error tracking alone.
Conclusion#
Frontend observability represents the same shift backend systems went through years earlier: moving from scattered, tool specific monitoring toward a single, standards based tracing model. With OpenTelemetry now mature enough in the browser to support this in production, and major observability platforms shipping native support for it, this is a practical time for frontend teams to start treating the browser as a first class part of their observability strategy rather than a blind spot at the edge of it.
References#
Grafana: Frontend Observability with Real User Monitoring
OneUptime: How to Get Started with OpenTelemetry as a Frontend Developer
OneUptime: How to Set Up OpenTelemetry Browser Instrumentation for Real User Monitoring