JavaScript error monitoring

JavaScript error monitoring with logs, replay, and AI triage.

Catch browser exceptions, unhandled promise rejections, failed fetches, source-mapped stack traces, and release regressions in one production debugging path.

Squasher error monitoring dashboard with correlated telemetry panels
TypeError spikecheckout web@2201

AI triage linked the exception to checkout logs, a session replay, a trace span, and the release that changed the failing path.

Capture

Capture the browser failures users actually hit.

Squasher keeps JavaScript errors close to the route, release, source map, replay, logs, and user impact needed to debug the failure.

Browser errors

Capture uncaught exceptions and component failures with stack traces and releases.

Promise rejections

Track async failures that never reach a route handler or visible error boundary.

Network failures

Keep failed fetch breadcrumbs beside the user action and response workflow.

Release regressions

Connect new error groups to deploy metadata and source-mapped application frames.

Workflow

Connect stack traces, source maps, logs, replay, and user impact.

The page crash matters less as a standalone event than as a regression with context engineers can verify.

01

Install the browser SDK

Initialize once when the app boots so global browser errors, rejections, vitals, breadcrumbs, and replay can be correlated.

02

Ship release and source map metadata

Tag each deploy and upload matching source maps so minified stack frames point back to application code.

03

Group by cause and impact

Use releases, routes, users, logs, and replay to separate noisy duplicates from customer-impacting regressions.

04

Review the AI triage summary

Let Squasher gather likely cause, affected surface, and next steps while engineers keep final review.

Setup

Set up browser-side JavaScript monitoring.

Use the browser SDK for framework-agnostic frontend capture, then add source maps and replay where production debugging needs readable context.

import { init } from "@squasher-ai/browser";

init({
  apiKey: import.meta.env.VITE_SQUASHER_API_KEY,
  projectId: import.meta.env.VITE_SQUASHER_PROJECT_ID,
  environment: import.meta.env.MODE,
  release: import.meta.env.VITE_GIT_SHA,
  captureConsoleErrors: true,
});

FAQ

JavaScript error monitoring FAQ.

Short answers about source maps, replay, browser support, network failures, and keeping frontend monitoring useful.

What JavaScript errors should production monitoring capture?
Capture uncaught browser errors, unhandled promise rejections, failed fetch breadcrumbs, release metadata, source-mapped stack traces, and the session context around the failure.
Do I need source maps for JavaScript error monitoring?
Yes for readable stack traces in bundled production code. Upload source maps for each release so responders can inspect application files instead of minified frames.
How does session replay help JavaScript debugging?
Replay shows the user flow, clicks, route changes, and UI state before the exception, which helps when a stack trace alone does not explain how the bad state was reached.
Can JavaScript monitoring include network failures?
Yes. Browser SDK breadcrumbs and explicit capture around fetch failures can connect network errors to route, release, user impact, and the surrounding session.
Does JavaScript monitoring hurt frontend performance?
Keep collection scoped to supported SDK defaults, release tags, sampling, and privacy settings. Squasher is meant to add debugging context without turning every browser event into noise.