Crash Reports

When the tab dies, so does your error reporting

JavaScript error monitoring cannot report its own death. If the browser crashes on your page, the script that would have told you went down with it. Crash Reports come from the browser itself, delivered to us after the fact, about the sessions nothing else could describe.

Start Free Trial Documentation →
What's at Stake

A crash is the one failure your instrumentation cannot witness.

Every client-side monitoring tool works the same way: some JavaScript runs on your page, catches a problem, and sends a message about it. That arrangement holds for exceptions, for failed requests, for slow renders — and stops holding the moment the renderer process itself goes down. There is no handler to fire, no beacon to send, and no page left to send it from. The session simply ends, and every tool you own records a visitor who left.

No Witness

Your error tracker died in the same crash

Script-based monitoring depends on the page surviving long enough to report. A crash removes both the problem and the thing that would have described it, so the more severe the failure, the less likely you are to hear about it.

Indistinguishable from Leaving

Analytics records a bounce, not a failure

In your metrics a crashed session looks like someone who lost interest. Both are a page view with nothing after it. Without a separate signal there is no way to separate the users you frustrated from the users you actually broke.

Nobody Tells You

Users blame the browser, not the site

A crash produces a browser error page carrying none of your branding. Most people retry once, then leave, and very few contact anyone. The behaviour that would surface the problem is precisely the behaviour that does not happen.

What Crash Reports Do

The browser reports what the page could not

Crash reporting is part of the Reporting API, so the browser observes and reports rather than anything of yours. One response header enables it, and the reports describe sessions that ended without warning.

Crash Capture

A record of the sessions that ended abruptly

When the browser or one of its components goes down on your page, it notes what happened and delivers a report once it is running again. Because the report goes to our endpoint rather than yours, nothing about the delivery depends on the page, the script, or the tab that just disappeared.

Learn more about the Reporting API →
Patterns, Not Anecdotes

One crash is noise; a hundred on one page is a bug

Individual crashes are hard to act on and easy to dismiss. Aggregated by page, reason and user agent, they stop being anecdotes: a memory exhaustion clustered on a single view, or on one browser and device class, points at something specific in what that page loads.

Learn more about Network Error Logging →
One Header, Three Products

The same setup you already need for the rest

Crash, Deprecation and Intervention reports all arrive through the Reporting API and all share a single Report-To header. If you have set that up for any one of them, the others cost nothing further to enable — and a report type you were not expecting is often the one that turns out to matter.

Learn more about Deprecation Reports →
Get Started

Find the sessions that ended badly. Not just the ones that ended.

One header. No code. Crash reports arrive from the browser itself.

Start Free Trial Talk to our team →

30-day free trial  ·  One header  ·  No code  ·  Cancel anytime

Detection

What a crash report carries

Crash reports are deliberately sparse — the browser is describing an event during which it was not in a healthy state. What they do carry is enough to group and locate the problem.

Reported What it tells you
reason: oom The renderer ran out of memory — frequently a heavy page on a constrained device
reason: unresponsive The page stopped responding and was terminated
Page URL Which view the user was on, so the problem has somewhere to live
User agent The browser and platform, which is often where the pattern is
Timestamp When it happened, so it can be lined up against a release

Crash reporting is not implemented identically across every browser, so treat the volume as a signal about your own pages over time rather than as a complete census of every crash that occurred.

Architecture

One response header. No code. No crawlers.

Crash reporting is part of the browser, delivered over the Reporting API. There is no script of ours on your pages — which is the point, because a script could not survive the event it is meant to describe. Reports come to our endpoint, so nothing about their delivery depends on your site being healthy.

One header enables the whole Reporting API. The same record covers crash, deprecation and intervention reports.

Minimal setup — the Reporting API endpoint
Report-To: {"group":"default","max_age":31536000,
  "endpoints":[{"url":"https://your-subdomain.report-uri.com/a/d/g"}]}

Your unique endpoint is on your Setup page once you have an account. Nothing else is required — the browser decides when there is something to report.

No code added to your pages

Nothing of ours to crash alongside your page

Reports reach us even when your site does not

Your site's performance is unaffected

The same header also enables deprecation and intervention reports

Reporting API

Three report types, one deployment

The Reporting API is a single mechanism carrying several kinds of message from the browser. Crash reports tell you a session ended badly. Deprecation reports warn that something on your page is scheduled to stop working. Intervention reports tell you the browser overrode what your page asked for, in the interest of performance, security or the user.

All three arrive through the same header, so the marginal cost of the other two is nothing.

Intervention Reports →
Scope

One layer in the stack. Here's how it fits.

Crash Reports cover sessions that ended when the browser gave out. They do not tell you why the page was heavy, and they do not catch ordinary JavaScript exceptions — this is the last-resort signal, and it works alongside the rest.

Crash Reports do Pairs with
Record sessions the browser terminated Network Error Logging for visitors who never arrived at all
Group crashes by page and user agent Deprecation Reports for features scheduled to stop working
Survive the failure they describe Intervention Reports for behaviour the browser overrode
Need no script on the page Script Watch for what those pages are loading in the first place

Together, these use the browser's own reporting to describe what your visitors experienced, rather than what your servers believe they served.