How to Monitor JavaScript Errors on a Website: Two Approaches

Why JavaScript error monitoring matters

Modern websites rely on JavaScript for rendering, state, forms, product data, checkout steps, analytics, personalization, and application behavior. When that JavaScript fails, the page may still respond while the user experience breaks.

Basic uptime monitoring often misses these failures because it checks whether the server responded. JavaScript error monitoring looks at what happens inside a real browser after the page starts loading — capturing runtime crashes and console.error messages that never surface in a simple HTTP check.

How NorthDuty monitors JavaScript errors

Start with the pages where JavaScript failures would hurt most: signup, login, checkout, pricing, product pages, landing pages, dashboards, and forms.

NorthDuty opens each page in a real Chromium browser via Playwright and captures two types of JavaScript errors: page-level runtime errors (uncaught exceptions and unhandled rejections, the pageerror event) and meaningful console.error messages. Both are grouped and surfaced per check run.

JavaScript errors form their own critical error group called Page script. Each new critical group reduces the Errors subscore by 25 points, and Errors accounts for 20% of the overall 0–100 health score. That means recurring JavaScript errors can drop a healthy score noticeably even if the page stays reachable.

Broken-resource detection runs alongside error capture. Missing scripts and failed bundles are common reasons front-end behavior breaks and they appear as a separate group. For the most important flows, user journey monitoring confirms whether an error actually blocks the next customer action.

Which one to start with

If you own the codebase and the question is "why did this break for that customer", start with an SDK. Nothing else gives you the stack trace, the release, and the specific browser. Budget a week of tuning to silence extension noise and third-party scripts, or the signal disappears under it.

If you look after sites you did not build — an agency roster, a client's WooCommerce store, a marketing site behind someone else's CMS — start with scheduled checks. You cannot add an SDK to a site you do not deploy, and in most cases you do not need one: you need to know that the checkout page threw an error during last night's plugin update, which an outside check answers without touching the site.

The two also fail differently in the case that matters most. When a JavaScript error stops the page rendering at all, the SDK may never get the chance to report it — the reporting code is on the page that did not finish loading. A check that renders the page and then asks whether any visible content exists does not have that problem, which is why blank-page detection belongs on the outside-in side.

Conclusion

JavaScript errors are a major reason websites break while still appearing online. Monitoring them requires running a real browser — not just checking whether a URL responds — and capturing both uncaught runtime errors and console.error messages.

NorthDuty captures both types in every health check run. They contribute directly to the Errors component of the health score, which weighs 20% of the total. That means JavaScript errors on your most important pages show up as a measurable score drop, not just a silent log entry.