Crash-free rate is not a health check

Every launch review I sit in still opens with a crash-free session chart. Someone has drawn a red line. Someone else has a screenshot from last Tuesday. The room then argues about tenths of a point as if the app had a fever.

Crash-free rate is a volume-weighted convenience metric. It moves when who uses the app moves. A payday weekend in Thailand brings older Android devices and longer checkout sessions. Songkran brings travel apps and weaker hotel Wi-Fi. Neither event is a regression. Both will drag the line.

In the flagship programme we ask students to split the same week three ways: by OS major, by new versus returning session length, and by entry point (push versus organic). Almost every “quality drop” we have seen in Bangkok cohorts collapsed into a mix shift in at least one of those cuts.

What to put on the launch page instead

Name three clusters that can actually kill a journey. Give each an owner and a hold condition. If none of those clusters moved, a crash-free dip is a weather report. You may still investigate; you should not halt a staged rollout on weather.

Teams hate this because the chart is simple and the clusters are not. Simplicity is not the same as truth. If your PM only has time for one number, give them affected users on a named journey, not a session percentage with two decimals.

A mild exception

If you ship to a single device class — a kiosk build, a one-SKU handset — mix bias shrinks and crash-free becomes less theatrical. Most consumer apps in SEA are the opposite. Treat the metric as a prompt to open the export, not as a verdict.

Related reading: when stability alerts should wait, and the flagship syllabus module on release gates.