Crash-Free Users vs Crash-Free Sessions: What Crashlytics Actually Measures

The short answer

Crash-free users is the percentage of distinct users who did not experience a crash in the selected period. One user who crashes ten times counts once against the metric.

Crash-free sessions is the percentage of app sessions that ended without a crash. A session starts when the app comes to the foreground and ends when it is backgrounded or terminated. Ten crashes across ten sessions count ten times.

The two numbers are related but never interchangeable:

Crash-free sessions is almost always the higher number, because a heavy user with one bad crash generates many good sessions alongside it. If your crash-free sessions look healthy but crash-free users has dropped, you have a crash that hits a specific segment hard — a device model, an OS version, a locale, or a single code path. That divergence is the single most useful signal on the Crashlytics dashboard.

How Crashlytics calculates them

Firebase Crashlytics computes both over a rolling window you choose in the dashboard (last 24 hours, 7 days, 30 days, and so on):

crash-free users    = 1 - (users who had >= 1 crash / total users)
crash-free sessions = 1 - (sessions with >= 1 crash / total sessions)

Two things trip people up. First, only crashes count — non-fatal errors you log yourself and ANRs are reported separately and do not move these two percentages. Second, both metrics depend on the Analytics SDK being present for session counting; without it, session-based numbers are unreliable.

What benchmark should you hold?

• 99.9%+ crash-free users — what a mature, well-maintained consumer app should hold.
• 99.5%–99.9% — acceptable, but you have a recurring defect worth a sprint.
• Below 99% — users are noticing. Expect review damage and churn.

Set the floor per release, not per quarter, and check it against the previous version rather than an absolute target — a 0.3% drop on a new build matters more than the absolute figure.

Crashlytics vs Sentry, briefly

Crashlytics is free, deeply integrated with Firebase, and its crash-free metrics are the industry reference point. Sentry costs money but gives you full stack traces with source maps across mobile and backend, richer release health, breadcrumbs you control, and performance tracing in the same tool. We run both: Crashlytics for the headline stability metric and store-facing health, Sentry for actually diagnosing the defect. The rest of this article is the playbook we use to keep those numbers where they should be.

Keeping Crash-Free Sessions > 99 %: Our Playbook with Crashlytics + Sentry

A single crash can nudge a five-star app to four-point-something—and bump you down the App Store or Google Play rankings. At THE USEFUL APPS we treat stability as a feature; every client retainer includes a guarantee that crash-free sessions stay above 99 %.

Below you'll find the exact monitoring, triage, and release loop we've refined while maintaining apps like RouteMate and PHNews. Pairing Firebase Crashlytics (for mobile-first signal) with Sentry (for full-stack visibility) gives us near-real-time insight without drowning our devs in alert fatigue.

Table of Contents

1. Why 99 % Isn't Just a Vanity Metric
2. Our Two-Layer Monitoring Toolkit
3. Instrumentation Checklist (iOS, Android & Flutter)
4. Alert Routing: Noise ⟶ Signal
5. Release Annotation & Regression Hunting
6. Hot-Patch Workflow (24-Hour Fix Pledge)
7. Maintenance Retainer Tie-In
8. Sentry vs. Crashlytics: Which Handles What?
9. Security & PII Considerations
10. Key Metrics We Track
11. Conclusion

TL;DR

1. Instrument everything (Crashlytics SDK + Sentry mobile & back-end SDKs).
2. Route alerts through a single Slack channel with severity filters.
3. Annotate releases so we can bisect instantly.
4. Hot-patch critical issues via feature flags; ship store updates within 24 h.
5. Close the loop by feeding crash metrics into sprint retros.

1. Why 99 % Isn't Just a Vanity Metric

Google's internal research shows a direct correlation between crash rate and uninstalls , while Apple's ranking algorithm quietly penalises apps with high "User Terminated" signals. Falling from 99 % to 97 % sounds minor—but if you have 100 k daily sessions, that's 2 000 crashes per day.

Keeping the number above 99 %:

• Protects your App Store rating
• Reduces churn (RouteMate saw a 3 % retention lift after we fixed a background-fetch crash)
• Boosts conversion in paid campaigns (nobody installs a 3.8-star app)

2. Our Two-Layer Monitoring Toolkit

Crashlytics handles native stack traces across Swift, Kotlin, Flutter, and React Native. Sentry handles our Node, Python, or Go back-ends plus any React in webviews. Together, they give us a single view from tap to database write.

3. Instrumentation Checklist (iOS, Android & Flutter)

We commit a monitoring.md file in every repo documenting SDK versions, manual uploads, and DSNs. That doc lives next to the CI config so future engineers see the full picture.

4. Alert Routing: Noise ⟶ Signal

Raw Crashlytics alerts = chaos. We pipe both Crashlytics and Sentry through AWS SNS ➔ Slack with opinionated filters:

1. Blocklisted: Known-benign Tesla BLE failure? Ignore.
2. Critical: New crash > 0.1 % sessions within one hour -> page engineer on duty.
3. Moderate: New crash group with < 0.1 % sessions -> Slack thread.

This reduces false positives by ~70 % compared to default email alerts.

5. Release Annotation & Regression Hunting

In both tools we tag every CI build with:

• Git SHA
• Semantic app version
• Feature flag bundle
• Jira sprint ID

Crashlytics then shows "First seen in 2.13.0 (Build #231)" so PMs can bisect instantly. Sentry's Release Health dashboard tracks crash-free sessions per build , highlighting regressions we might have missed.

6. Hot-Patch Workflow (24-Hour Fix Pledge)

When a critical crash surfaces:

Our RouteMate engagement once hit a nasty SIGABRT in iOS 17 RC. Flag rollback cut crashes to zero in 90 minutes; the store patch landed next day.

7. Maintenance Retainer Tie-In

This process lives inside every Maintenance & Support plan. Clients know exactly what happens when a spike appears—no awkward "scope" arguments. For details on the tiers, read App Maintenance Strategies for Long-Term Success.

8. Sentry vs. Crashlytics: Which Handles What?

We keep both, but if you only have budget for one and your stack is 100 % Flutter, Crashlytics alone covers 95 % of pain points.

9. Security & PII Considerations

• Use Crashlytics data redaction rules to strip email/phone from logs.
• In Sentry, set sendDefaultPii = false and add beforeSend hook.
• Ensure DSNs and Google Service Plist files are stored as GitHub Secrets.
• SOC 2 clients often require 90-day log retention; both tools support that.

10. Key Metrics We Track

We pull these into a Monday morning Looker Studio report for each client.

Conclusion

Maintaining > 99 % crash-free sessions isn't magic—it's disciplined instrumentation, fast feedback loops, and the willingness to hot-patch at 3 a.m. Using Crashlytics for native signal and Sentry for end-to-end context, we've helped brands like Skip hold five-star ratings year after year.

Want this playbook applied to your app? Reach out or explore the specifics of our Care, Growth & Scale plans—each one includes the 24-hour fix pledge.