Does Google Play punish your app for crashing?

Yes — and unusually for a store policy, the line is published to two decimal places. Google will quietly reduce your app's visibility once your crash or ANR rate crosses a documented threshold. The thresholds themselves are easy to look up. The part that catches people out is how the rates are counted, which is why the number in your Play Console rarely matches the number on your own crash dashboard.

The published lines

Google calls them bad behaviour thresholds, and there are four of them in the stability group:

1.09% — the overall user-perceived crash rate. If at least that share of your daily users experience a crash they can see, across all device models, you're over. 0.47% — the same idea for ANRs, the "app isn't responding" dialog. And two per-device lines, both 8%: if 8% of daily users on one single device model hit a crash, or an ANR, that model alone is enough to flag you.

The consequence is not a rejection email. Google's wording is that an app over a threshold "is likely to be less discoverable on Google Play," that users on affected device models get steered away from your app specifically, and that in some cases Play shows a warning on your store listing suggesting higher-quality alternatives. It is a ranking and merchandising penalty, applied silently, that no amount of listing work will offset.

Why your own dashboard shows a different number

Nearly every crash SDK reports crash-free sessions or crashes per session. Play counts per daily active user. That single difference moves the number a long way in whichever direction your usage pattern happens to lean.

Take an app where a user opens the app six times a day, and one of those sessions in a hundred crashes. Per session, that's a 99% crash-free rate — a figure you could put on a slide. Per user per day, the odds that at least one of six sessions crashed is around 6%. That is five times over Google's overall threshold, from a metric that looked respectable an hour ago. Run the same arithmetic on a utility people open once a week and it falls the other way. Neither dashboard is lying; they are answering different questions, and only one of them is the question Play asks.

Two more quirks worth internalising. Play's data comes only from users who opted into sharing usage and diagnostics, on Play-certified devices, for installs that came from Play — so it is a sample, not a census, and an app with low volume may not show data at all. And the thresholds are evaluated on a 28-day rolling average, checked daily. That cuts both ways: a single catastrophic release day won't flip you instantly, and a fix you ship today won't clear the average for weeks. Nothing about this metric is same-day.

The per-device threshold is the one that gets you

Most teams watch the headline number and never open the per-device breakdown. That's backwards. A crash confined to one manufacturer's mid-range handset — a vendor-specific camera path, a GPU driver quirk, an OEM background-process killer — can sit at 10% on that model while your overall rate stays a tidy 0.4%, because the model is 3% of your install base. Your overall number never moves. Play still steers every user on that device away from your listing.

This is also the failure mode you cannot reproduce. It lives on hardware you don't own, often in a region you don't ship from. The per-device tab in Android vitals is the only place it's visible before the reviews arrive.

ANRs are the tighter budget, and nobody treats them that way

Look at the two numbers again: 1.09% for crashes, 0.47% for ANRs. Google's tolerance for a frozen app is less than half its tolerance for one that dies outright — which is the right call, because a crash at least ends. Yet crashes get the alerting, the dashboards and the on-call rotation, and ANRs get looked at when someone remembers.

An ANR has no stack trace pointing at your bug. It's the symptom of main-thread work that ran too long: a synchronous disk or network call in a lifecycle method, a broadcast receiver doing real work, a database migration on first launch after an update, a lock held across a slow call. They cluster on cold start and on the first launch after an update — exactly the moments where a new user decides whether your app is any good. If you're going to instrument one thing this quarter, instrument startup.

And on the other store?

Apple publishes no equivalent threshold. There is no documented crash rate at which App Store search demotes you, and Xcode's Organizer gives you crash data from users who opted into sharing analytics with developers, without a stated line to stay under. That doesn't make crashes free on iOS — the penalty just arrives through ratings and reviews instead of through ranking, which is slower to appear and much slower to undo. The practical difference is that on Android you can measure your exposure against a number, and on iOS you can't.

One thing worth planning for either way: from February 2027, Google has said memory usage, bitmap memory usage and code optimisation join the metrics that affect visibility. If your app leans on large images — and a screenshot or design tool certainly does — that's a line item to look at well before it lands, not after.

What this changes about shipping

The useful reframe is that stability is part of the acquisition funnel, not a separate engineering concern that lives after launch. You can write the best listing on the store, and a 28-day average over 1.09% will quietly undo the ranking you earned. The two work on the same number.

In practice that means a staged rollout for anything touching startup, so a bad build meets 1% of users rather than all of them; a per-device glance before you widen the rollout; and a habit of reading the ANR chart with the same seriousness as the crash chart. None of that is heroic. It's just the part of the funnel that doesn't look like marketing.