Docs

Crashlytics Web Support: What to Track

Firebase Crashlytics is extending to web apps — track crash parity across mobile and web now, before two separate error pipelines drift apart.

Performance

Firebase Crashlytics has covered iOS and Android since it was acquired into Firebase, but until now, teams shipping a companion web app or a web-based checkout flow have had to run a second, unrelated error-tracking tool — usually Sentry, Bugsnag, or raw window.onerror logging — alongside it. Google’s rollout of Crashlytics web support, built on Cloud Observability so web errors and traces land in the same Cloud Logging and Trace backend as server-side data, closes that gap. For product teams that already treat mobile crash-free-session-rate as a release gate, the obvious next step is holding the web surface to the same bar.

The risk in this transition is a false sense of parity. Turning on Crashlytics for web doesn’t automatically make your web crash data comparable to your mobile crash data — different error taxonomies, different severity thresholds, and a web stack that silently swallows more errors by default than a native app does. A team that migrates and assumes “crash rate” now means the same thing across both platforms, without checking, can end up making a release decision on a web number that isn’t actually catching what the mobile number always caught.

Data Points to Track

  • crash_free_session_rate computed separately for web and mobile, plus a combined figure, so a platform-specific regression doesn’t get diluted into a blended number that looks fine.
  • error_severity — fatal, unhandled, and caught-but-logged — classified consistently across both SDKs, since web JavaScript errors default to a much wider “caught” bucket than native crashes do.
  • stack_trace_source_map_resolved — whether a web error’s minified stack trace was successfully mapped back to source, which determines whether the crash report is actually actionable or just noise.
  • platform and sdk_version on every crash event, so you can tell a genuine web-side regression apart from one introduced by the Crashlytics web SDK integration itself.
  • ai_cluster_id if you’re using Crashlytics’ ML-based crash grouping, tracked per platform to confirm clustering quality holds up on the web’s messier stack traces before you rely on it for triage.

Setup Steps

  1. Enable Crashlytics for your web app alongside the existing mobile integration, and confirm errors are landing in the same Firebase project rather than a separate one.
  2. Define a shared error_severity taxonomy across mobile and web before comparing crash-free rates, since “fatal” on a native app and “uncaught exception” on the web aren’t automatically equivalent.
  3. Wire up source maps for your web build so minified stack traces resolve to real file and line numbers — without this, web crash reports are close to useless for triage.
  4. Set a web-specific crash-free-session-rate release gate, separate from your mobile threshold initially, until you’ve validated the numbers are comparable.
  5. Cross-check AI-clustered crash groups on web against a manual review for the first few weeks, since the clustering model has more mobile crash history to learn from than web.

Actionable Insights

Once mobile and web crash data sit in the same pipeline, the most useful first output isn’t a combined crash-free rate — it’s the gap between the two. A web crash-free rate that’s meaningfully lower than mobile, even after normalising severity definitions, usually points to real gaps in error handling that were previously invisible because nothing was watching. Use the stack_trace_source_map_resolved rate as a leading indicator of report quality before trusting any web crash trend: a low resolution rate means you’re triaging noise, not real regressions, no matter what the headline crash rate says.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert