Monitor JavaScript Errors in the Frontend (First-Party)

Why Server-Side Checks Miss JS Errors

Classic monitoring checks whether a server is reachable and which status code it returns. A page can be served with HTTP 200, load its HTML completely - and then break only in the visitor's browser because a script throws a runtime error. The server has done its job; the error happens solely on the device. This class of failure is invisible to server-side checks because it does not reach the server at all.

The data underlines how widespread the problem is. An empirical study of production websites found that JavaScript errors fall into a small number of categories and can be both deterministic and non-deterministic - meaning they partly depend on the specific browser, device and user path (UBC study, Ocariza et al.). An error that does not appear in the developer's test browser can still reliably strike on an older mobile device. Testing only on your own laptop does not reveal this variety.

Making matters worse, modern pages rely heavily on scripts. Imported libraries, tag managers, widgets and frameworks each bring their own code - and any of those sources can throw an exception that halts the rest of the script. A related class of silent frontend failures is covered in the article on monitoring CORS configuration errors, since a request rejected by CORS often ends up as an equally invisible JavaScript error.

How the Browser Reports Errors: onerror and unhandledrejection

The browser provides two central mechanisms to capture runtime errors. The global window.onerror handler receives synchronously thrown exceptions and provides message, source, line, column and the error object (MDN Web Docs). Asynchronous errors from unhandled promises instead surface in the unhandledrejection event (MDN Web Docs). Only both together cover the bulk of unhandled errors.

Robust frontend capture therefore combines several sources: the global onerror handler for synchronous exceptions, the unhandledrejection listener for failed promises, capture of network errors, and - where needed - framework-specific error boundaries (Inspectlet 2026). Listening to only one of these sources systematically misses an entire class of errors.

// Synchronous runtime errors
window.addEventListener('error', (e) => {
  report({
    kind: 'error',
    message: e.message,
    source: e.filename,
    line: e.lineno,
    col: e.colno,
    stack: e.error && e.error.stack
  });
});

// Unhandled promise rejections
window.addEventListener('unhandledrejection', (e) => {
  report({
    kind: 'unhandledrejection',
    message: String(e.reason && e.reason.message || e.reason)
  });
});

In practice, a home-grown solution quickly hits limits. Errors from cross-origin scripts are reduced by the browser to the generic message Script error. for security reasons - without the crossorigin attribute and matching CORS headers, the stack trace and detail are missing (MDN Web Docs). Minified production code also yields cryptic positions like checkout.min.js:1:48213 that are hard to map to a concrete code location without source maps (Rollbar). A mere collection of raw events is therefore of little value - what matters is enrichment, grouping and trend analysis.

First-Party Instead of a Third-Party Script

Many error-tracking approaches load an external script from a foreign domain. That is problematic for two reasons: first, that very script is another third-party tracker that must be handled under data protection law; second, scripts with well-known tracker file names are frequently blocked by browser extensions and filter lists - which means the errors of users with an active blocker go missing. First-party means the capture is served from your own domain and the data flows to your own infrastructure.

XICTRAQ captures JavaScript errors via the already-embedded, cookieless first-party tracker. The same mechanism that measures page views and Web Vitals also listens to onerror and unhandledrejection and sends the events to your own analysis. This adds no extra third party, and the error data sits in the same dashboard as the other metrics. How closely frontend quality and loading behaviour are linked is also shown in the article on continuous accessibility monitoring against WCAG - both are aspects a pure server check does not capture.

A common objection is that errors are already visible in server logs or in the browser console during development. Both fall short, however. Server logs by their nature do not contain client-side exceptions, because those do not reach the server in the first place. And the console only shows what becomes visible on the one device someone happens to be sitting at - it says nothing about how often an error occurs in the real user base, which browser versions are affected, or whether the frequency has risen after a release. Only the aggregated view across many real sessions turns individual observations into a reliable statement about frontend health.

What XICTRAQ Monitors in the Frontend

Frontend monitoring is more than collecting error messages. It is about turning raw events into an understandable picture: which error hits how many users, on which page, in which browser, since which release. The overview below shows the signals that together form a reliable picture of frontend health.

The key is normalising to the error rate per page view. An absolute error count inevitably rises with traffic - 500 errors on a campaign day can be entirely normal, while 50 errors overnight may be an alarm signal. Only the rate makes time periods and pages comparable and lays the foundation for reliable anomaly detection.

Prioritising Frontend Errors Correctly

Not every captured error deserves the same attention. The browser generates a substantial amount of noise that has little to do with the actual application: a browser extension injects code that fails; an ad blocker aborts a request; an outdated browser does not know a function in use. Treating such events as critical errors leads to alert fatigue - the state in which a team ignores warnings because too many of them are irrelevant. Robust frontend monitoring therefore separates the signal from the noise instead of weighting every console message equally.

Prioritisation typically follows three questions. First: how many users are affected? An error on 30 percent of sessions weighs more than a one-off. Second: where does it happen? An error in the checkout or the login form is business-critical, an error on a rarely visited archive page less so. Third: since when has it occurred? An error that appeared with the last deploy points to a fresh regression and should be checked first. Exactly these dimensions - frequency, location and timing - are delivered out of the box by grouped, enriched capture, whereas a bare list of raw console messages hides them.

In practice, a simple approach helps: first sort errors by affected sessions, then look at the business-critical pages first, and finally check whether a rise coincides with a release. This creates a ranking that follows the actual damage rather than the loudest console message. This way of working keeps the effort manageable even when new entries arrive every day - because only what noticeably affects users and revenue gets handled. It is just as important to keep an eye on an error once it has been fixed: if it reappears after a later release, that is a clear sign of a returned regression which, without continuous observation, could easily go unnoticed a second time. A persistent history view makes such relapses visible and separates them from genuinely new findings.

Detecting Error-Rate Anomalies After Deploys

The most common cause of a sudden rise in frontend errors is a deploy. A changed script, an updated dependency or a renamed DOM element - and code throws an exception that did not exist before. Since high-performing web teams release often, there are many opportunities for such regressions. This is exactly where continuous observation of the error rate helps: instead of waiting for a fixed threshold, monitoring compares the current value with a learned baseline from previous weeks and triggers when the rate jumps significantly above it.

Baseline (Mon-Thu, per 1,000 page views):
  6.8  errors/1k   normal range (mean 7.1, sigma 1.4)

After deploy v42 (Fri 09:14):
  09:20   8.1  errors/1k   still within range
  09:28  21.4  errors/1k   above threshold (mean + 3 sigma)
  09:30  31.0  errors/1k   +340% vs baseline

  Top error:  TypeError: cannot read 'total'  (62%)
  Browser:    Safari iOS 17                   (88%)
  Page:       /checkout

=> Anomaly 14 min after deploy v42 - alert triggered

The value lies in the interplay of detection and context. The alert does not just report that the error rate has risen, it delivers the diagnosis right away: which error type dominates, which browser is affected and on which page it happens. In the example, it is immediately clear that a TypeError in the checkout mainly hits Safari on iOS - a lead that points the team straight to the offending release. The same principle of target-versus-actual deviation is used by monitoring API rate limits and 429 responses, where a sudden rise likewise signals a fresh regression.

Why a Fast Response Protects Revenue

Frontend errors cost twice: directly through abandoned transactions and indirectly through lost trust. A survey found that 51% of mobile internet users have already encountered a website that crashed, froze or showed an error (Google / Search Engine People). Such experiences rarely lead to a complaint - most users leave the site without a word. The damage happens quietly and stays invisible without monitoring.

Proximity to performance metrics matters too. Pages that load in two seconds or faster have a bounce rate of around 9%, while pages taking five seconds rise to around 38% (Google). Layout shifts and blocking scripts - often a consequence of JavaScript problems - worsen these figures and can lead to misclicks and missed conversions (web.dev). Errors and performance are therefore not separate topics but two sides of the same frontend health.

The difference is not just speed but the quality of information. A user complaint delivers at best 'the button doesn't work'; an anomaly alert delivers error type, affected browser and page. That removes the time-consuming reproduction step and lets the team start directly at the offending release.

1. Capture - listen to onerror and unhandledrejection first-party from your own domain
2. Enrich - attach browser, version, device, page and time to every error
3. Normalise - look at errors per 1,000 page views rather than absolute numbers
4. Group - combine similar errors so mass errors become visible
5. Alert - notify on a significant deviation from baseline, with diagnosis

Frontend Monitoring as Part of the Bigger Picture

JavaScript errors are one building block of complete website monitoring. A server can be reachable, the certificate valid, the DNS configuration clean - and the customer still fails at a script error. Conversely, a smoothly running frontend is of little use if DNSSEC validation of DNS security fails or links lead nowhere, as the article on automated 404 and broken-link monitoring shows. Only the combination of these signals creates a reliable picture.

The practical value lies in bringing all these layers into one interface. When error rate, uptime, certificate status and performance sit side by side, an incident can quickly be assigned to the right layer - instead of guessing across several tools. Frontend error monitoring complements classic availability monitoring exactly where the latter is blind: on the visitor's device.

A deploy cannot be prevented, and it should not be - fast releases are an advantage. What can be prevented is a frontend regression silently costing revenue for hours. That is exactly what first-party JavaScript error monitoring is for: it turns the invisible error in the browser into a visible, alertable signal.

Frequently Asked Questions About JavaScript Error Monitoring