By Specita
Crash-free users vs crash-free sessions, explained
Crash-free sessions count sessions that did not end in a crash. Crash-free users count people who never crashed. Learn when each rate misleads.
Crash-free sessions is the share of sessions that did not end in a crash. Crash-free users is the share of distinct users who did not have a single crash in the same period. The two numbers answer different questions. Sessions tell you how often the app fails when people use it. Users tell you how many people the failures reached.
Both Firebase Crashlytics and Sentry report both rates, and both define them the same way. The details that trip teams up are what counts as a session, how the period is aggregated, and whether user identity is available at all.
The two formulas
Firebase documents the calculations directly:
| Metric | Formula | Question it answers |
|---|---|---|
| Crash-free sessions | 1 - (crashed sessions / all sessions) | How often does a session end in a crash? |
| Crash-free users | 1 - (crashed users / all users) | What share of people avoided a crash entirely? |
Sentry describes the same pair in words. Crash-free sessions are sessions in the time range "not ended by a crash of the application". Crash-free users are distinct users who did not experience a crash during that period.
One crashed session makes its user a crashed user for the whole period. Another 50 clean sessions from that person do not change that.
Why the two rates move apart
The gap between the rates depends on how crashes are spread across people. Here is a hypothetical day for an app with 2,000 users and 20,000 sessions, with 40 crashed sessions in both cases:
| Scenario | Crash-free sessions | Crash-free users |
|---|---|---|
| 40 crashes concentrated in 5 users | 99.80% | 99.75% |
| 40 crashes spread across 40 users | 99.80% | 98.00% |
The session rate is identical. The user rate is not. In the first case, a handful of people hit a crash over and over, perhaps on one device model or one account state. In the second, a broad slice of the user base met the problem once.
So read the pair together:
- Users falling faster than sessions suggests a crash that reaches many people, even if each person sees it rarely. It is often the more urgent signal for a new release.
- Sessions falling while users hold steady suggests a smaller group crashing repeatedly. Look for a shared device, OS version, locale, or data condition.
- Both falling together is the plain case: more crashes, reaching more people.
What counts as a session depends on the platform
A crash-free session rate is only comparable when sessions mean the same thing. Sentry's release health documentation uses different session models:
| Platform type | When a session starts and ends |
|---|---|
| Mobile and desktop apps | Starts at launch or when the app returns to the foreground, and ends when it closes or goes to the background. A return within 30 seconds does not start a new session. |
| Browser apps | Starts on page load. Current JavaScript SDKs continue it across client-side navigations; SDKs before version 11 started a new session on each navigation. |
| Servers and APIs | Each request is a session, ending when the response is sent. |
That is why a 99.9% crash-free rate for an API and a 99.9% rate for an iOS app say very different things. Compare a release with earlier releases of the same component, not with a different platform.
Session settings also change the denominator. On Apple platforms, for example, Sentry ends a session after 30 seconds in the background by default, and sessionTrackingIntervalMillis changes that timeout. A longer timeout means fewer, longer sessions, and a different rate from the same crashes. Keep the setting stable when you compare releases.
Do not average daily rates
Firebase notes that both percentages are "an aggregation over time, not an average." Recompute the rate from the totals for the whole period instead of averaging daily percentages.
Another hypothetical: a quiet first day with 100 sessions and 10 crashes, then a busy day with 10,000 sessions and 10 crashes. The average of the two daily rates is 94.95%. The real crash-free session rate for the two days is 99.80%. A small day can drag an average far away from what most users experienced.
Not every bad session is a crash
Sentry separates session outcomes. Crashed means a hard crash. Errored means the session ended normally but recorded handled errors. Abnormal means the SDK could not tell whether the session ended cleanly, and these usually have no matching issue. Sentry also tracks unhandled sessions separately from crashed ones in recent versions.
Only crashed sessions lower the crash-free rate. A release can therefore look crash-free while users still hit handled errors, frozen screens, or failed requests. Pair the crash-free rate with your error counts and key user-flow checks.
Sentry also notes that the number of crashes "is not expected to match the number of crashed sessions." Session data is not sampled or filtered, while error events are subject to sampling, inbound filters and quotas. Do not expect the issue list to add up to the session totals.
Crash-free users needs user identity
The user rate depends on the SDK knowing who the user is. Sentry's JavaScript documentation says that to receive user adoption data and the users crash-free rate, you set the user when initializing the SDK. Without that, the session rate can still be reported while the user rate has nothing to count.
Mobile SDKs and Crashlytics have their own identity rules, so check your platform's documentation. If the user count looks suspiciously small or empty, identity is the first thing to check.
Small samples move the rate
At low volume, one crash moves the rate a lot. In Specita's own synthetic Sentry test project, a release with 120 recorded sessions and 6 controlled crashes showed 95.00% crash-free sessions. That example was built to test release attribution, not to represent a real app. But it shows the scale: each crash in 120 sessions is worth almost a full percentage point.
Before you call a release healthy or unhealthy, check the denominator next to the percentage. A rate based on a few dozen sessions is a prompt to wait, not a verdict.
Which rate to watch during a rollout
Use both, for different jobs:
- Release decisions: compare crash-free sessions for the new release with the previous release over equal windows, for the same component and environment. This is the most direct measure of whether the new build crashes more often.
- Impact and urgency: use crash-free users to judge how many people a problem reached, and whether support or a staged-rollout halt needs to happen now.
- Context: record the session count, the time window and the environment with every percentage you report.
A crash after a deployment is a lead to investigate, not proof that the latest change caused it. The post-deployment checklist covers how to keep delivery success and runtime health separate.
How Specita uses crash-free sessions
Specita reads crash-free session rates from Sentry for an exact SDK release and environment. It compares releases only over equal complete-hour windows after delivery, up to 24 hours, and requires at least 100 recorded sessions per version. Recorded sessions are not unique users or installed devices, and Specita does not yet report version share.
If your Sentry release shows no health data at all, start with why a Sentry release is not showing data.