Crash-free rate is the headline app-stability metric: the percentage of sessions (or users) that did NOT experience an app crash. Crashes are catastrophic UX events — the app force-quits, the user loses state, and confidence in the app erodes. Apps with high crash rates lose users to uninstall faster than acquisition can replace them, regardless of how good the rest of the product is.
Two flavors
- Crash-free sessions: percentage of all sessions that completed without a crash. Used for aggregate stability reporting. Lower-bound metric — if any single session crashes for a user, they "saw a crash" but their other sessions might be fine.
- Crash-free users: percentage of users who didn't experience ANY crash in a defined window (typically last 7 or 30 days). Higher bar — once a user crashes, they're "crash-affected" until the window resets.
Report both; they tell different stories. Crash-free sessions is the daily operational metric; crash-free users is the user-experience metric.
Modern benchmarks
- Consumer apps: 99.5%+ crash-free rate is the operational baseline. Top-tier apps run 99.9%+.
- Banking / healthcare / high-stakes apps: 99.9%+ minimum; users have zero tolerance for instability in critical workflows.
- Hyper-casual games: 98-99% is more common (rapid iteration, less QA). Acceptable trade-off given the short-session product shape.
- Below 99%: serious problem. Investigate immediately, ship hotfixes daily until resolved.
- Below 97%: existential. Pause new features, focus engineering on stability until recovered.
A 1% crash rate is not "just 1%" — it's catastrophic. If 1 in 100 sessions crashes and the average user has 5 sessions per week, roughly 5% of users will crash in any given week, 20%+ over a month. Each crash event meaningfully lifts uninstall probability — typical impact: a 1% crash rate (99% crash-free) drops D7 retention 10-20% and lifts D30 uninstall rate 15-30% vs a 99.5%+ baseline. Small absolute number, huge impact on the business.
Crash-tracking tooling
- Firebase Crashlytics — Google's free crash-tracking. The market leader by adoption (estimated ~70% of Android apps; substantial iOS share). Strong stack-trace symbolication, real-time alerts, BigQuery integration for deeper analysis.
- Sentry — strong cross-platform crash + error monitoring with broader scope (not just crashes, also non-fatal errors). Popular with engineering-led teams.
- Bugsnag (now SmartBear) — feature-comparable to Sentry, common in enterprise.
- Apple App Store Connect / Google Play Console — native crash dashboards from the stores themselves. Use as a cross-check; don't rely on these alone (limited stack-trace detail, slower aggregation).
Process discipline: every release should have a documented crash-free-rate gate before broad rollout. Phased rollouts (Google Play staged rollout, App Store phased release) let you catch a stability regression in 1-5% of users before it affects 100%. Set a clear threshold (e.g., "halt rollout if crash-free rate drops below 99.3% in the first 1% of users") and stick to it.