A 99.8 percent crash-free rate is a comforting lie.
It looks great on a slide. It looks great in a board update. It also hides which users are hurting, which devices are failing, and which flows are silently losing you revenue every week. Headline crash rate was useful ten years ago when apps crashed often. Today it is a number founders repeat without reading, and sometimes without noticing it is going down for the wrong reason.
Here is what a crash rate actually tells you, where it misleads, and what we read instead on every app we support.
99.8 percent crash-free sounds great, but do the math
99.8 percent crash-free sessions means one session in five hundred ends in a crash. For most apps that reads as low. For your actual customers, do the math.
Your heaviest users probably run twenty sessions a week. At 99.8 percent crash-free, that is one crash every twelve or thirteen weeks on average — if crashes were randomly distributed, which they are not. Crashes cluster. They cluster on specific devices, specific OS versions, and specific flows. Your heaviest users are hit multiple times a week while your light users are hit never.
That is why the headline number can trend up while your most valuable users are seeing the product get worse. The average is fine. The people paying you are not.
Sessions versus users is where the number gets honest
The quickest fix: swap your dashboard metric from crash-free sessions to crash-free users. A single buggy device model, hit by five percent of your base, barely moves the session number but hammers the user number. Crash-free users is the headline founders should read.
Then slice by device, OS version, and release build. One of three things is usually true:
- The latest release has a specific bug on one OS version — fix the release.
- An older device model is carrying a disproportionate share of failures — ship a device-specific guard or deprecate the model.
- A specific flow (payment, auth, media) crashes more than the average — fix the flow.
Any of those is a load-bearing finding. The headline rate is not; it is the summary of a thing you have not read yet.
Not every failure is a crash
The second lie in the crash number is that crashes are the only failures. They are not, and often not even the most expensive ones.
What slips past crash reporting:
- Application Not Responding (ANR) on Android. The app does not crash; it freezes. Users leave. Many Crashlytics dashboards do not surface ANRs at the top.
- Hangs on iOS. MetricKit reports hangs separately. A ten-second hang on a save flow is worse than a crash — crash ends it fast; hang lets the user watch the app rot.
- Silent failures. The call fails, the API returns an error, the app catches it, shows a soft toast, and the user walks away not knowing their data did not save. No crash, no funnel, lots of churn.
- Timeouts and offline-online transitions. Especially expensive in emerging markets. Report success internally, user never saw the result land.
Every one of those is invisible on a crash-rate chart. All of them cost revenue. Any founder reading only crash rate is making decisions on a fraction of the data.
Session depth matters more than session count
A crash on app launch is not the same as a crash during checkout. The headline rate treats them as equivalent events. Your P&L does not.
Tag crashes with the flow they occurred in. A crash near a save, a payment, a submission, a share, or a hand-off is worth multiples of a crash on home-screen scroll. If your top three flows are each generating a share of crashes greater than their share of sessions, that is the whole story — the number is secondary.
This is also why the 360io work we did started with the data layer and the monitoring layer together. Pretty graphs on a broken event schema is theatre.
Sentry and Crashlytics defaults flatter you
Neither tool is lying. Both are tuned to make a founder feel good about their app, because that is good for retention of the SDK. Patterns to watch:
Auto-grouping buries platform-specific bugs. One root cause can appear as three different crash signatures across OS versions and get grouped under the loudest. The quieter two look resolved; they are not.
Sampling at scale drops long-tail crashes. At high volume both tools sample. The crash hitting one percent of users may not be sampled meaningfully — which is exactly the crash concentrated on your biggest customers.
Severity labels are optional. Both tools let you label severity. Most teams never do. Without severity, a crash on first launch and a crash in payment look the same to the dashboard.
None of these are flaws in the tools; they are patterns in how the tools are used. Fix the usage first.
Crash rate is a vital sign, not a diagnosis. Reading it alone is like checking a pulse and claiming the patient is healthy.
What a healthy mobile app actually looks like
A quick reality bar:
- Crash-free users at 99.5 percent or better on supported OS versions. 99.9 percent is where premium apps live.
- No single device or OS version accounts for a disproportionate share of crashes.
- ANR / hang rate tracked separately with its own target.
- Payment, auth, save and share flows each tracked with their own crash-free rate.
- Each release ships with declining crash counts versus the prior release (within the first week of adoption).
- A weekly review — one named person, thirty minutes, documented actions.
If all six are true, your app is healthy. If only one is true (the headline number), you have a comforting lie on a dashboard.
What we do differently
On apps we support, we treat crash monitoring as a product surface, not a plugin. That means a release-tagged, device-sliced, flow-labeled dashboard reviewed weekly by someone with authority to act. On 360io we rebuilt the monitoring layer the same week we rebuilt the data layer, because one without the other is theatre.
It also means setting expectations about what post-launch health actually requires — a reality closer to what founders forget after launch than to a once-at-launch task.
FAQ
Is a 99.8% crash-free rate good for a mobile app?
On its own, no. 99.8% crash-free sounds great until you learn one in five hundred sessions is a bad one, and if your biggest users each run twenty sessions a week, several of them hit a crash every single week. Headline crash rate hides who is hurting.
What should founders watch instead of just crash rate?
Crash-free users rather than sessions, ANR rate on Android, hangs on iOS, silent failures where the app runs but the task does not complete, device clusters where one phone model carries the whole failure budget, and session depth — crashes near purchase or in a save flow matter far more than crashes on launch.
How do Sentry and Crashlytics mislead founders?
They do not lie, but their defaults flatter you. Session-based crash rate masks concentrated damage, auto-grouping buries platform-specific bugs, and sampling at scale drops long-tail crashes that happen to be the ones hurting your biggest customers. Read percentiles, not averages.
What is a healthy mobile app crash-free user rate?
99.5% crash-free users or better for a consumer app on recent OS versions is a reasonable floor; 99.9% is where premium apps live. Health is not just the number — stable builds show declining crash counts after each release, and no single device or OS taking a disproportionate share.
How does Eightinity treat crash monitoring in a shipped app?
We treat the monitoring stack as a product surface, not a plugin. Fingerprinted releases, device-model slices, severity labels tied to user intent, and a weekly review cadence make the data load-bearing. On 360io we rebuilt the monitoring layer the same week we rebuilt the data layer because one without the other is theatre.
Reading your crash data honestly for the first time? Book a free 30-min call →
