The Only Evidence of Fatal Browser Failures
When a browser tab crashes, your JavaScript environment is destroyed instantly. No error handler can run, no stack trace can be captured. Crash reports are the only evidence that a user's session ended in failure — not by choice.
The Problem
The Blind Spot in Your Error Monitoring
Your JavaScript error tracking sees exceptions, promise rejections, and runtime errors. But when a browser tab truly crashes — out of memory, renderer fault, or unresponsive script — your error tracking sees nothing. The JavaScript environment is destroyed before any handler can execute.
This isn't a limitation of your tools. It's fundamental to how browsers work. JavaScript is single-threaded. When memory runs out or the renderer process crashes, there's no thread left to report the problem. Your error tracking SDK can't send what it can't run.
Heavy single-page applications are especially vulnerable. Design tools like Figma warn users at 60% and 75% of browser memory — and lock files entirely at 100%. Data visualization dashboards, collaborative editors, and media-heavy applications routinely push against the 2GB per-tab memory limit that browsers enforce, even on desktop.
The numbers are sobering: out-of-memory errors account for roughly 10% of all browser crashes. And when researchers tested the top 10 most popular single-page applications, 10 out of 10 had memory leaks — even with skilled teams behind them. Memory management in complex web apps is hard.
The result is silent churn. Users experience crashes and simply leave. They don't report the issue — they assume something's wrong on their end, or they just give up. You see a session end and assume they closed the tab. You have no idea their experience ended in failure.
The Solution
Crash Reporting: When the Browser Itself Reports Failures
The Crash Reporting API is a WICG specification that lets browsers report crashes to an endpoint you control. Because the report is generated and delivered by the browser process — not JavaScript — it works even when your application code can't run.
Crash reporting is currently supported in Chrome 96+ and Edge 96+ (Chromium-based browsers).
When a tab crashes, the browser generates a report with the crash reason (like oom for
out-of-memory or unresponsive for killed tabs), the visibility_state at crash time, and
whether the crashed document was top-level.
Configuration requires just one HTTP header. No JavaScript SDK, no build process changes. The key insight is that crash reports are delivered out-of-band. The browser queues the report and delivers it on the next successful page load — or even from a different tab. Your JavaScript doesn't need to survive the crash. The browser handles everything.
The Challenge
But Crash Reports Need to Reach Your Tools
Crash reports tell you that a crash happened, but not why. Unlike JavaScript errors, crash reports don't include stack traces. You know memory ran out, but not which component or feature caused the leak. You know the tab was unresponsive, but not which operation hung.
The real value comes from getting crash reports into your existing observability tools. Your team already has dashboards, alerting rules, and workflows for analyzing errors. Crash reports need to flow into that same system so you can correlate them with deployments, filter by environment, and set up alerts.
But browsers send crash reports in a specific format (application/reports+json) to endpoints you
configure. Your observability platform speaks a different language. Someone needs to receive the browser reports,
parse them, and forward them in a format your tools understand.
Building that bridge yourself means writing and maintaining glue code. You need an endpoint to receive reports, validation logic, retry handling for failed deliveries, and adapters for each integration target. It's undifferentiated work that distracts from your actual product.
The Answer
Route Crash Reports to Your Observability Stack
We collect crash reports and forward them to your existing tools for analysis and alerting.
-
Visibility Into Invisible Failures
- See crashes that JavaScript error tracking can never catch. When the browser tab dies, your error SDK dies with it. Crash reports survive because the browser itself sends them.
-
Route to Your Stack
- Send crash reports to AppSignal, webhooks, or Google Chat. Integrate with your existing alerting and monitoring tools. Analyze crash patterns where you already analyze everything else.
-
No JavaScript SDK
- Configure one HTTP header and you're done. The browser handles collection and delivery. No client-side code to maintain, no bundle size impact, no SDK that crashes with your app.
-
Analyze in Your Tools
- Your observability platform handles the analysis. Correlate crashes with releases, filter by browser, and set up alerts using the tools your team already knows.
Ready to See When Your App Crashes?
Stop losing users to silent failures. Know when browser crashes end sessions — and correlate them with your releases to improve stability.