A crash-free user percentage without a declared baseline is just a number on a wall. Before a feature freeze, we ask teams to lock three values: the last release they still trust, the device classes that represent most paying users, and the minimum observation window after a staged expand.
Why freezes break naive baselines
During a freeze, engineers stop shipping large changes, but marketing pushes and OS updates continue. If your baseline was taken during a quiet holiday week, the freeze may look “worse” even when the binary is healthier. Compare like with like: same day-of-week windows, same rollout percentage, same major OS mix.
A practical baseline sheet
Write down the build identifier, crash-free users at 24h / 72h / 7d after 100% (or after your usual expand point), top three crash signatures that were accepted as known, and the ANR rate you treated as normal. Keep that sheet beside every go / hold discussion.
When to reset
Reset after a major architecture change, a forced OS migration, or when you deliberately accept a new class of crashes (for example, a third-party SDK you cannot yet replace). Document the reset date so future assessments do not mix eras.