How to Monitor Frontend and Browser Apps with OpenTelemetry

What to capture in the browser

Frontend monitoring with OpenTelemetry comes down to a handful of client-side signals plus the connection to the backend. You want document and resource load timing, the Core Web Vitals (LCP, INP, CLS), route changes in single-page apps, the latency of fetch and XHR calls the page makes, and JavaScript errors and unhandled rejections, all carrying session and page context. The signal that makes this genuinely powerful is the link to the backend: when the browser propagates trace context on an outbound request, the front-end span and the server span join into one trace, so a slow interaction can be followed from the click all the way to the database call behind it.

How to instrument with OpenTelemetry

The OpenTelemetry Collector is the workhorse here: it receives telemetry over OTLP and exports it to your backend, so instrumentation stays vendor-neutral and portable. For the browser you use the OpenTelemetry JavaScript SDK for the web (the web trace SDK) with auto-instrumentations for document load, fetch and XHR, and user interaction, plus an integration that reports Core Web Vitals. Because browsers cannot speak gRPC, you export over OTLP HTTP to a Collector, which then forwards to your backend. The one detail that makes or breaks end-to-end traces is context propagation on outbound requests: configure the fetch and XHR instrumentation to inject trace headers so the browser span links to the server span, and make sure the backend and any CORS policy accept those headers.

Key metrics to watch

The signals that explain most frontend experience problems:

What to put on a dashboard

A frontend dashboard should show experience first, then cause. Row one is the Core Web Vitals at the 75th percentile per page or route, the numbers that reflect real experience and affect SEO. Row two is stability and errors: JavaScript error rate by page and browser, so a browser-specific or deploy-specific break is obvious. Row three is cause: slowest resources and fetch/XHR latency by endpoint, and, ideally, the front-end-to-backend trace view so a slow interaction links to the server work behind it.

# Core Web Vitals at p75 by page (the numbers that matter)
histogram_quantile(0.75, web_vitals_lcp) by (page)
histogram_quantile(0.75, web_vitals_inp) by (page)

# JavaScript error rate by page and browser (catch a bad deploy)
sum(rate(browser_js_errors[5m])) by (page, browser)

# is a slow interaction the backend? fetch latency from the browser
histogram_quantile(0.95, http_client_request_duration) by (http.url)

Reading the signals: common failure modes

Poor LCP

The page feels slow to appear because the largest element takes too long to render, usually a big unoptimised image or a slow server response for the main content, or render-blocking resources. LCP at p75 above the threshold on a page is the signal. Optimise the largest element and its critical path; the resource timing shows which asset is the culprit.

High INP

The page is slow to respond to clicks and taps because long JavaScript tasks are blocking the main thread. INP rises while load metrics may look fine. Break up long tasks, defer non-critical work, and reduce heavy third-party scripts so the browser can respond to input promptly.

Layout shift (CLS)

Content jumps around as the page loads, so users mis-click and the experience feels janky, because images or embeds have no reserved space or content is injected above the fold late. CLS above the threshold flags it. Reserve dimensions for media and avoid inserting content above what the user is viewing.

JavaScript error spike

Error rate jumps on a specific page or browser right after a release, because a deploy introduced a client-side bug or an incompatibility. The error rate by page and browser pinpoints it, and the trace links the failing interaction to any backend call involved. Roll back or fix the client-side change.

Example alert conditions

Reasonable starting thresholds, assessed on real-user field data:

From monitoring to autonomous resolution

Ops Singularity's TelemetryOps pillar ingests this OpenTelemetry frontend data natively, correlated with the backend traces behind each interaction, and Sentinel AI resolves the incidents it reveals, a deploy spiking JavaScript errors, an API slow only from the browser, a Core Web Vital regression, through governed Action Tickets validated by Sherlock. Explore TelemetryOps and ServiceOps.