JS Errors Guide: Automatic JavaScript Error Tracking in statpx

Broken JavaScript rarely announces itself. A visitor's cart button silently stops working, a form fails to submit, or a whole widget goes blank — and unless they email you, you never find out. The JS Errors page in statpx exists to close that gap: it captures real client-side errors from real visitors, automatically, with zero setup beyond the standard tracking snippet.

What Gets Captured Automatically

The moment the statpx tracking snippet is installed on a page, it attaches two listeners in the background:

• window.onerror — catches uncaught JavaScript exceptions: type errors, reference errors, syntax errors thrown at runtime, anything that would otherwise only show up in a visitor's browser console.
• unhandledrejection — catches promises that reject without a .catch() handler, which is one of the most common sources of silent failures in modern JavaScript (failed fetch calls, async functions that throw, etc.).

Both are wired up by default. There is no flag to enable, no extra script tag, and no sampling rate to configure — every page that has the snippet installed is already reporting errors.

How Errors Are Grouped

Raw error events are noisy: the same underlying bug can fire thousands of times across thousands of sessions. The JS Errors dashboard groups events by message, source file, line number, and page so you see one row per distinct bug instead of an endless duplicate list. Each group shows:

• How many times the error fired in your selected date range
• How many unique sessions were affected
• Which page(s) it occurred on
• The exact source file and line number where it was thrown

This turns "something is broken somewhere" into "this specific error, on this specific line, on this specific page, hit N visitors this week" — enough detail to open a ticket and start debugging without waiting for a user report.

Reading the JS Errors Dashboard

Start with the summary counts at the top: total error events, unique error messages, and pages affected. From there, sort the grouped list by occurrence count to find the highest-impact bug first — a rare error on a rarely-visited page matters far less than a common one on your checkout flow. Click into a page name to see how error volume correlates with traffic on that page; a spike in errors right after a deploy is a strong signal the deploy introduced the regression.

Turning Error Data Into Fixes

Because every error is tied to a real page and a real occurrence count, you can prioritize fixes the same way you'd prioritize any other bug backlog — by actual user impact rather than by whichever bug report reached you first. A practical workflow:

1. Sort by occurrence count and fix the top 1–2 errors each week.
2. Check the affected page against your broken link and 404 tracking — a page riddled with both dead links and JS errors is usually overdue for a rebuild, not a patch.
3. Re-check the same error group a few days after shipping a fix to confirm the occurrence count actually dropped to zero.

The Bottom Line

Most JavaScript bugs never reach a bug tracker because visitors don't report them — they just leave. The JS Errors page gives you visibility you'd otherwise never get: every uncaught exception and rejected promise, grouped by message and page, ranked by real impact. It costs nothing to enable because it's already running the moment the tracking snippet is installed — check it regularly, and treat a rising error count with the same urgency as a traffic drop.