Skip to Content
FeaturesCrash Analytics

Crash Analytics

Find out what’s breaking on your website — automatically.

This feature is available on the Premium plan and above.

Overview

Crash Analytics logs the JavaScript errors your real visitors hit: uncaught errors and unhandled promise rejections are captured automatically on every tracked page, with no changes to your tracking code. Industry measurements suggest around 13% of all pageviews carry a lurking JavaScript error — errors your team never sees because they happen on browsers and devices you don’t test.

For a healthcare site, a broken appointment form is worse than a lost pageview. Crash Analytics tells you what failed, where, and for whom — before patients start calling.

Open the Crashes reports in the left reporting menu to explore what’s been captured.

What’s Captured

For each crash, Ghost Metrics records:

  • The error message and type (e.g., TypeError)
  • The stack trace and the source file, line, and column where it occurred
  • The page URL where the visitor experienced it
  • When the crash was first seen and last seen
  • The visit context — so you can see what the affected visitor was doing

Similar occurrences are grouped into a single crash, so a bug that hits a thousand visitors shows up as one line with a count — not a thousand lines.

Reports

  • Real-time crash monitoring — What’s failing right now; invaluable in the minutes after a deploy
  • New, reappeared, and disappeared crashes — New bugs, regressions of bugs you thought were fixed, and confirmation that fixes worked
  • Crashes by page — Which pages produce the most errors, so you can prioritize by impact
  • Crashes by source — Filter first-party vs third-party scripts and custom categories to separate your bugs from someone else’s

You can segment other reports by visits that experienced a crash, add crash widgets to your dashboards, and receive scheduled crash summaries by email.

Alerts

Set up alerts to be notified when new crashes appear or crash counts spike — so a broken release gets caught in minutes, not at the next reporting meeting.

Managing Crashes

Crash lists stay useful when they stay curated:

  • Merge similar crashes that are really the same bug reported slightly differently
  • Ignore known noise — for example, errors thrown by a third-party embed you can’t fix

Debugging Workflow

  1. A new crash appears (or an alert fires)
  2. Open the crash to read the message, stack trace, and affected pages
  3. Check the visit context — browser, OS, device — for a reproduction recipe
  4. If you use Session Recordings, watch a recording of an affected session to see exactly what the visitor did
  5. Ship the fix, then confirm the crash moves to disappeared — and watch for it in reappeared

Manual Crash Tracking

Automatic capture covers uncaught errors. For errors your code catches and handles, you can report them explicitly:

// Track a caught error object (an Error instance, or any object with a message)
_paq.push(['CrashAnalytics::trackJsError', new MyApiError('the error message')]);
_paq.push(['CrashAnalytics::trackJsError', { message: 'my error message' }]);
 
// Fully manual crash tracking
_paq.push(['CrashAnalytics::trackCrash', 'my error message', 'my error type']);

To turn automatic capture off (or back on) for a page:

_paq.push(['CrashAnalytics::doNotTrackUncaughtErrors']);
_paq.push(['CrashAnalytics::trackUncaughtErrors']);

Server-side and mobile application crashes (PHP, Android, iOS, Java) can also be tracked via SDKs — contact support if you’d like help instrumenting an application.

Privacy Considerations

Error messages and stack traces are captured as your site produces them. If your application embeds sensitive values in error messages or URLs (tokens, patient identifiers, query parameters), those values can end up in crash data:

  • Keep sensitive data out of thrown error messages
  • Review captured crashes on pages that handle patient information
  • Use ignore for third-party errors you don’t want retained

Best Practices

  • Watch real-time crashes after every deploy — the fastest feedback loop you can get on release quality
  • Prioritize by page value, not raw count — ten crashes on the appointment form outrank a thousand on a blog archive
  • Triage weekly — merge duplicates and ignore noise so the “new crashes” signal stays trustworthy
  • Track caught errors at key boundaries — API failures in your booking flow are worth reporting with trackJsError even when handled gracefully

Limitations

  • JavaScript errors are captured from tracked pages in browsers — errors from bots or on pages without the tracking code aren’t seen
  • Stack traces are reported as your site serves them; minified code produces minified traces (keep a source map on hand to decode them locally)
  • Third-party scripts can produce noise — use source filtering and the ignore action

Next Steps

Last updated on
Multi Channel AttributionRoll-Up Reporting