Two surprises in browser crashes
You might be surprised, as I was, to learn that Chrome exposes an API to notify you when the browser crashes on your page. It is part of a larger reporting API that is designed to give browsers a channel to inform you, the developer, of crashes and other things.
In particular for a page crash you no longer have a page or JS context to receive the event, so the API instead POSTs some JSON to a URL you provide. Per usual there were two slightly incompatible versions of the API, I imagine as they attempted to standardize. (I do not know a lot about this space but it appears all of this is Chrome-only for now…)
Figma, which is a large complex web app that often breaks browsers, uses these to monitor for crashes. That is how I learned these systems existed — I was on call and an alert fired about the crash rate.
And here is where the second surprise appeared: the alert fired because the crash rate was high, but a separate dashboard monitoring the crash rate appeared low. The discrepancy turned out to be caused by a misconfiguration. We were segmenting the incoming crashes by which portion of the site they affected, and the two systems slightly disagreed on what they were watching.
The crash rate in the core app, the browser-busting magic WASM WebGL piece that I was attempting to monitor, had stayed level. The crash rate on a relatively static HTML marketing page had risen! The marketing page, as I recall, had some of those swoopy CSS animations on scroll that is common on today's marketing pages, and (edit: I had this wrong in the first post, thanks Andrew!) an accidental change in ad targeting was bringing in a bunch of users with lower-end mobile browsers that would crash.
From this I took away an important lesson: even when your app is not pushing the
boundaries of browsers, monitoring for crashes is probably worth it.
Read this overview to
get started; I believe it's as simple as providing a default endpoint in an
HTTP header and accepting POSTs there.