Frontend errors: why users see problems before your team does

Published 18 August 2026 · Updated 18 August 2026 · Merik team · 7 min read

Frontend errors are failures that happen in the user's browser after the server has successfully delivered the page — JavaScript exceptions, unhandled promise rejections, failed API calls, and scripts or resources that never load. They are invisible to server-side monitoring by construction: the server did its job, returned a 200, and logged a success. The failure happened afterwards, on a machine you do not control, in one of a thousand browser-extension-network combinations you cannot reproduce. Detecting them requires monitoring in the one place they actually occur: the browser itself.

The gap between "delivered" and "working"

Server-side monitoring — uptime checks, status codes, server logs — verifies delivery: the request arrived, was processed, and a response went out. For a static document, delivery is the whole job. For a modern web application it is roughly the first half.

After delivery, the browser must parse and execute a JavaScript bundle, hydrate or render the UI, attach event handlers, and begin making its own API calls. Any of those steps can fail — and when one does, the user is left with something that looks like a page: it has a header and a layout and perhaps a spinner, but the button does nothing, the form will not submit, the data never arrives. From the server's perspective, this session was a success.

This is the structural reason users report problems while every dashboard is green: the dashboards watch the half of the work that succeeded.

The four kinds of frontend failure

• Uncaught exceptions. A JavaScript error at runtime — reading a property of undefined, calling a method that does not exist on some browser, a null that slipped through. Depending on where it lands, it can kill one interaction or the entire application shell.
• Unhandled promise rejections. The async variant, and in modern codebases the more common one: a fetch fails, a .catch is missing, and the flow that depended on it silently never completes. Nothing crashes; something just never happens.
• Failed network requests. The page is fine but its API calls return 4xx/5xx or time out. The browser knows — the server-side view attributes the failure to the API, if it is noticed at all, and never connects it to the broken experience it caused.
• Failed resources. A script, stylesheet or image that never loads — a CDN hiccup, an ad-blocker, a renamed bundle after a deploy. A single failed script tag can take out every feature that script powered.

Why nobody reports them

The comforting assumption is that if something were really broken, users would say so. The data from every team that has ever added frontend error collection says otherwise. Users almost never report errors, for predictable reasons:

• They blame themselves — "probably my internet" — and retry. If the retry works, nothing was ever wrong as far as anyone will hear.
• Reporting is work — finding a contact form, describing what happened, answering "what browser are you on?". A visitor with a broken checkout has an easier option: a competitor.
• The error is invisible even to the user. An unhandled rejection that stops a save from completing shows no red text. The user believes the save worked. This is the worst class: data quietly not happening.

So the reporting rate rounds to zero, and the one report you do get — "the page doesn't work" — arrives with no error text, no browser, no reproduction steps. Meanwhile the browser knew the exact exception, file, line and stack the whole time. Frontend monitoring is simply deciding to collect what the browser already knows.

How frontend error monitoring works

The mechanics are straightforward and standard:

1. A small script in the page registers for the browser's global error events — uncaught exceptions, unhandled rejections, resource failures — and optionally observes failed fetch calls.
2. Errors are reported to a collection endpoint in small batches, with the message, the source file, and the page path. A sensible reporter caps its queue and never lets its own reporting break the page it watches.
3. The collector groups them. Ten thousand users hitting the same bug produce ten thousand near-identical messages differing only in IDs and numbers. Normalising those away and hashing the shape — the fingerprint — turns a flood into a short list: this error, this many times, since this hour.
4. Rates are judged against that site's own baseline. Every real-world site has background errors (extensions, ancient browsers, bots). The signal is never "there are errors"; it is "this hour has 18× the usual errors", which almost always means a deploy just broke something.

Privacy is a design requirement, not a feature. Error messages and URLs love to carry tokens, emails and query strings. A responsible pipeline strips query strings, redacts token-shaped and email-shaped content before storage, sets no cookies, and collects no user identity. This matters doubly if you run other people's websites — you are instrumenting their users.

From error list to action

Collection is only useful if it changes behaviour. Three practices make it operational:

• Watch the rate, not the existence. Alert when the hourly count deviates hard from that site's normal — that is a regression, usually a shipped one. The background hum is a backlog, not an alarm.
• Read errors next to deploys. An error spike minutes after a deployment names its own suspect. Monitoring that holds both timelines answers "what broke?" and "what changed?" in one view.
• Treat network-class errors as API monitoring evidence. A cluster of failed POST /api/orders reports from browsers is often the first visible sign of a backend problem — before the API's own checks confirm it, because users generate far more traffic than probes do.

Quick reference

Definition	Failures occurring in the browser after successful page delivery — exceptions, rejections, failed requests, failed resources
Why server monitoring misses them	The server completed its work and logged a 200; the failure happened afterwards, client-side
Typical user response	Retry, self-blame, leave — reported in only a small minority of cases
Detection method	In-page reporter → collection endpoint → fingerprint grouping → rate vs the site's own baseline
The alerting signal	Hourly error count many times the site's usual hour — not the mere presence of errors
Privacy essentials	Strip query strings, redact tokens/emails, no cookies, no user identity
Highest-value correlation	Error spikes read next to deployment events

Frequently asked questions

How Merik handles it

Merik's browser SDK is a single script tag — no build step, no dependencies. It reports uncaught exceptions, unhandled rejections, failed requests and failed resources from real browsers, capped and de-duplicated so a runaway error loop cannot flood anything. Privacy is enforced twice: the snippet never reads cookies, form contents or query strings, and the collector redacts token-shaped, email-shaped and card-shaped content again on arrival before anything is stored.

Errors are grouped by fingerprint into hourly counts per site, so "user 4821 not found" and "user 9317 not found" are one bug with a counter, not two thousand rows. Each site's own history sets its normal; when an hour runs many times that normal, it feeds the asset's early warning alongside uptime and latency evidence — and if a deploy landed just before, the warning says so. The failures your uptime checks structurally cannot see, finally on the same screen as the ones they can.

Create your workspace →

Or talk to us about your team →