Your app will crash. Every production application eventually throws an unhandled error, experiences a segfault on Android, or hits an OutOfMemoryError that brings it down. The question isn't if — it's whether you notice before your users do, and whether you're shipping code that is demonstrably more stable than the last release.
Crash-free rate is the clearest signal of stability you can track. It measures the percentage of sessions (or users) that completed without hitting a crash, and small swings in this metric translate directly to app ratings, retention, and the phone calls you won't get at 3 a.m.
What is crash-free rate?
Crash-free rate is simple in concept but powerful in practice: it's the percentage of distinct sessions or users that experienced zero crashes during a defined time window or across a specific release.
If your app ran 10,000 user sessions today and 150 of them hit a crash, your session crash-free rate is 98.5%. If 140 unique users were affected by any crash during the day, your user crash-free rate is 98.6%. Both numbers are part of the same story — crashes happen, and the more sessions complete without hitting one, the more stable your app feels to real users.
Most teams track both. Session-based rates catch temporary spike bugs that affect a few users heavily. User-based rates show you the percentage of your audience that had a problem. For a mobile app especially, the difference matters: one user with a crash loop that reappears ten times a day skews the session rate but is just one user in the user rate.
Why crash-free rate matters more than you think
Here's the hard truth: crash-free rate predicts retention and ratings more reliably than almost any other metric.
App stores rate and rank apps partly on crashes. A 1% crash-free drop (moving from 99.0% to 98.0%) often correlates with a measurable increase in one-star reviews within 48 hours. Users don't write detailed bug reports — they uninstall. Losing even 0.5 percentage points across your user base for a week can cost you thousands of ratings points and real revenue if you're monetized through subscriptions or ads.
The reason is simple: crashes destroy trust. A user's mental model is "this app breaks easily," not "this app has one specific bug I should report." Every crash — whether it's a null pointer you've never seen or a race condition that only happens under load — makes your app feel broken. Crash-free rate is the aggregate of all those moments.
Web and backend services track crash-free rate too, but for different reasons. A 99.5% crash-free rate on your API might sound great until you realize 0.5% of billions of daily requests is millions of errors. For your backend, crash-free rate complements error budgets and SLOs — it's a behavioral measure of "did we stay standing?" — but for mobile and client-side apps, it's your primary north star.
How crash-free rate is calculated
The calculation depends on whether you're measuring sessions or users, and how you define a crash.
Session-based: Count the total number of sessions in a time window. A session is a distinct app launch or continuous foreground activity. A crash "completes" a session even if the app auto-recovers. Divide crashes by total sessions.
session_crash_free_rate = (sessions_without_crash / total_sessions) * 100
User-based: Group sessions by user ID. If a user had any crash across any session during the window, count them as affected. Divide unaffected users by total active users.
user_crash_free_rate = (users_without_any_crash / total_active_users) * 100
The tricky part is defining a crash. LightTrace reports crashes that hit your error tracker — uncaught exceptions, panics, segfaults that the OS reports, and OutOfMemoryErrors. Some teams include ANRs (Android Not Responding) in the definition; others treat them separately as a slower kind of crash. The key is consistency: pick a definition, keep it, and compare week-over-week and release-over-release.
Always segment crash-free rate by release. "Overall 99.0% crash-free" is useful, but "the new release is 98.7% crash-free vs 99.2% in the previous one" tells you immediately whether a deploy made things worse.
Crash-free rate as an early-warning system
Crash-free rate drops before users uninstall or leave bad reviews. That makes it your early-warning system.
The pattern is reliable: a bad deploy ships, crash-free rate drops 0.5–2% within the hour, and within 6–12 hours, rating scores start sliding and support tickets spike. Teams that monitor crash-free rate in real-time catch the deploy within the hour and rollback before it becomes a PR disaster.
Set up an alert that pages you if crash-free rate drops more than 0.5–1% hour-over-hour for your production release. That's the threshold where users start noticing and the review impact begins. For smaller apps, 0.5% might represent hundreds of affected users. For massive apps, even 0.1% can matter. Alert rules tuned to crash-free rate trends let you sleep soundly knowing you'll catch regressions before they compound.
Per-release vs aggregate
The real power of crash-free rate comes from tracking it per-release. Every time you ship, get a fresh baseline for that version:
- Release A: 99.1% crash-free for the first week, then settles at 98.9%.
- Release B: Launches at 97.8%, drops to 97.2% by day three — regression detected.
That tells you not just whether Release B is more stable than Release A (it's not), but when in its lifecycle the issue started and who was affected (the first 10% of users to auto-update). If you correlate crashes by stack trace, you might see that 95% of the new crashes are a null pointer in a specific code path — now you know exactly what to rollback or fix.
Don't obsess over matching a competitor's published 99.9% crash-free rate. That number often omits a definition of "crash" or only counts production users who opt into analytics. Track your own numbers honestly, and improve release-over-release.
Connecting crash-free rate to your release process
Crash-free rate is most useful when it's wired into your release workflow. Here's the pattern:
- Measure baseline — tag every event with a release before it ships, and baseline crash-free rate on the previous release.
- Monitor on deploy — watch crash-free rate in the first hour after deployment. A 1%+ drop is a regression signal.
- Correlate with changes — if a crash-free drop coincides with a deploy, GitHub source links and release tags let you jump straight to the code that changed.
- Set thresholds — configure alerts based on your app's velocity. A consumer app shipped to 100 million users should alert at a smaller percentage drop than a B2B SaaS shipping to 50 accounts.
Release health monitoring and error alerting best practices go deeper on this workflow, but the core is simple: you can't improve what you don't measure. Crash-free rate turns "our app is stable" into a number you can defend.
Crash-free rate across platforms
Mobile apps track crash-free rate obsessively because mobile crashes are highest-friction for users. An Android app or iOS app crash means the user loses context, waits for a re-launch, and often doesn't come back.
Web apps can track crash-free rate too — counting user sessions where the page remained interactive and no unhandled error was thrown — but web crashes are often less fatal (the user refreshes and moves on). That said, if your SPA crashes frequently, session-based crash-free rate is a great metric to own.
Putting it into practice
Start today. Set up LightTrace or another error tracker, tag every error with a release, and grab your baseline crash-free rate for your current production version. Now tag your next release and compare week-over-week. The goal is simple: never ship a release more than 0.5% less stable than the previous one.
Start tracking errors in minutes
Start tracking crash-free rate by release — point your Sentry SDK at LightTrace and ship with confidence.
Crash-free rate is the metric that matters because it's the one your users feel. Every point of improvement is a user who completes their session, leaves a five-star review, and tells their friends. Track it, alert on it, and make it the north star of your release process.