Crash-free session percentages are comforting. They compress thousands of launches into a single slope. They also flatten the journeys that matter most to revenue or care outcomes.
When onboarding or checkout is the failing path, the affected share of sessions may stay small enough that the headline rate barely moves. Support hears the problem first. Application analytics may show a funnel drop without a matching crash spike if the failure is an ANR or a soft freeze that users abandon.
What to inspect before the next stand-up
Start with the journeys that define success for the release, not with the tallest stack in the reporter. Compare those journeys’ crash and ANR rates against the prior stable build on the same device and OS bands. If the reporter allows, filter to the versions that hold most of your active users rather than the bleeding-edge minority.
Then read a handful of samples end to end. Ask whether the user was mid-payment, mid-login, or idle in a secondary screen. Ranking by raw count alone will keep sending engineers after noisy but low-stakes null pointers.
A short habit for release weeks
Keep a one-page “journey watch list” beside the crash dashboard. Update it when the candidate build changes. The list does not replace deep interpretation, yet it stops the team from congratulating a green crash-free chart while the path that pays the bills is quietly fraying.