Reading crash notes without turning one number into a pass/fail

A crash-free session rate is a useful clue about a candidate build. It becomes harmful when the freeze meeting treats a single threshold as the whole decision. Builds fail in particular screens, on particular devices, in particular languages. A blended rate will hide that.

When we read crash notes we ask for three cuts: the candidate versus current production, the top crashing screens, and any cut by OS version you actually support. If you cannot produce those cuts, say so. A missing cut is better recorded than replaced with a reassuring average.

Then we ask what you will do if the rate drops after the first staged step. If the answer is “watch it,” that is not a halt rule. A halt rule names the drop, the window, and the person who can stop the next percentage. Without those three, you have a chart for the meeting and hope for the weekend.

Soak time is the other number that masquerades as a decision. Two days of soak on a staff list is not the same as two days in the countries you ship to. If the app is used heavily on Friday nights in Malaysia, a Tuesday–Wednesday soak has not seen the load you care about.

Write the cuts and the halt rule into the packet. Leave the motivational reading of the average out of the report. The meeting will thank you by being shorter.