The bad-behaviour threshold is a door, not a score

What the door actually blocks

When Android Vitals places an app in the bad-behaviour band for user-perceived crash rate, the practical sting is discoverability and the warning in the console — not a moral judgement about the team. For a local supermarket app or a state-adjacent service, that warning still arrives in the same red text as it does for a global social product.

The threshold is set by Play. We do not negotiate it. What we can do is name the clusters that contribute to the user-perceived rate, because that rate is not one bug. It is usually three signatures and a long tail.

Percentages without signatures

A sprint that aims to “get under the line” without clustering will ship a splash-screen delay or a catch-all try/catch and call it stability work. User-perceived crash rate can even look calmer if a crash moves earlier and users stop opening the screen that died — which is not a fix.

In the finding pack we write cluster share in affected users for that window, not a headline percentage stripped of version codes. A 1.2% rate on a version that only ten thousand people received is a different object from 1.2% on the production track.

Staged rollouts and the delayed blush

Malaysian evenings are when many grocery and e-wallet sessions peak. A Friday production promote can look calm on Saturday morning in the office and ugly by Sunday night once Xiaomi-heavy cohorts catch the stagger. A pre-release gate on the testing track will not catch that fully, but it will catch signatures that already exist in internal testers before you pay for the weekend.

Request an audit briefing if this is the cluster on your desk this week.