Crash-free users rate
Crash-free users rate is the percentage of active users who used an app over a period without hitting a crash. It is a mobile stability metric, distinct from crash-free sessions, which counts at the session level. Because one user can have many sessions, the two rates differ: a single crashing user can drag the user-based rate while barely moving the session-based one.
What this means
Crash-free users rate divides users with no crash by total active users over a window. It is a standard stability metric in mobile crash-reporting tools (for example Firebase Crashlytics reports both crash-free users and crash-free sessions). The user-based framing answers 'what fraction of people had a clean experience,' which maps more directly to user impact than session-based counts.
Users versus sessions
Crash-free sessions and crash-free users measure the same crashes against different bases. Because users typically have multiple sessions, a crash that recurs for a small number of heavy users can show a high crash-free session rate yet a noticeably lower crash-free user rate. Reporting both prevents a misleadingly reassuring session number from hiding a problem concentrated in specific users or devices.
Segment by app version, device, and OS to localize a regression rather than reading the global rate alone.
- Users with no crash ÷ active users, per window
- Distinct from crash-free sessions (session base)
- Surfaces crashes concentrated in specific users
How it appears in analytics and logs
A drop in crash-free users after a release flags a regression affecting real people. The user-based view weights each person once, so it surfaces crashes that hit many distinct users even if each crashes only occasionally.
Diagnostic use case
Track app stability from the user's perspective so a release's quality is judged by how many people hit a crash, not just how many sessions did.
What WebmasterID can help detect
WebmasterID's observability surface tracks error and exception signals first-party, complementing app crash reporting with web-side stability without third-party identifiers.
Common mistakes
- Reading crash-free sessions and assuming users are equally fine.
- Putting PII into crash logs or stack traces.
- Reading the global rate without segmenting by version and device.
Privacy and accuracy notes
The rate is an aggregate ratio of unaffected users to active users. Crash reporting must avoid collecting personal data in stack traces or logs. This is educational, not legal advice.
Related pages
- Error rate
Error rate is the proportion of requests, page loads, or interactions that fail over a period. It comes in several flavors — server-side HTTP error rate (5xx/4xx share), client-side JavaScript error rate, and failed-interaction rate — each with its own numerator and denominator. As a RUM and reliability metric it signals broken experiences, but only when the failure definition and base are stated clearly.
- Real user monitoring (RUM) metrics
Real user monitoring (RUM) measures web performance from actual visitors' browsers in the field, as opposed to synthetic lab testing in a controlled environment. Its headline metrics are the Core Web Vitals — Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift — collected via the browser's performance APIs. Field data reflects real devices and networks, so it varies far more than lab numbers.
- The exception event (error tracking)
An exception event records that a client-side error occurred — a JavaScript error or a failed operation. GA4 supports an exception event for this. Tracking errors in analytics ties reliability to behaviour: you can see which pages throw and whether errors correlate with drop-off. The catch is that error messages and stack traces can leak personal data, so what you capture needs care.
- Website observability
Track web-side error and stability signals first-party.
Sources and verification notes
- Firebase — Crashlytics crash-free users and sessionsCrashlytics reports crash-free users and crash-free sessions rates.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.