Android vitals and visibility: the 1.09% crash and 0.47% ANR thresholds

Android vitals is the Play Console report on your app's technical quality: crashes, ANRs (App Not Responding), start-up time, rendering and battery use. A few of these metrics, the core vitals, feed directly into how visible your app is on Google Play. Cross a bad behavior threshold and Google says your app is likely to be less discoverable.

Last checked on 5 November 2026 against Play Console Help.

What are the Android vitals bad behavior thresholds?

Google Play sets bad behavior thresholds on the core vitals. These are the ones that apply to phone and tablet apps:

Google Play generally considers the last 28 days of data when it evaluates quality, but it may act sooner when there is a spike.

How are crash and ANR rates calculated?

Both rates are shares of daily users, not shares of sessions or crashes. A daily user is one user on one device on one day: someone who uses your app on two devices counts twice, and two people sharing one device count once.

• User-perceived crash rate is the percentage of daily users who had at least one user-perceived crash. It is lower than the overall crash rate because it leaves out crashes the user probably did not notice.
• User-perceived ANR rate is the percentage of daily active users who had at least one user-perceived ANR. It is lower than the overall ANR rate for the same reason.
• Multiple-crash and multiple-ANR rates count users with two or more, which points to loops.

The data comes from users who opted in to share usage and diagnostics data, on a subset of devices and Android versions. It excludes uncertified device models and app versions not installed through Google Play, and it is updated daily.

How do bad vitals affect visibility on Google Play?

Quality is one of several signals behind store search (the others are in how App Store and Google Play search ranking works). For vitals, Google states three effects:

1. Lower discoverability: if your app exceeds a bad behavior threshold, it is "likely to be less discoverable on Google Play".
2. Device steering: if the bad behavior is on specific device models, Google Play steers users on those devices away from your app towards more suitable ones.
3. Store listing warning: in some cases a warning appears on your listing to set user expectations and offer alternatives with higher technical quality.

Google does not publish how many positions a bad vital costs, and it ranks search on "a combination of ratings, reviews, downloads, and other factors". Crashes also cost you indirectly: they produce one-star reviews and uninstalls, which feed those other signals.

What are the DAU/MAU and user loss rate thresholds?

These two "core value" metrics measure whether people keep using the app, not whether it is stable. Google's wording:

Google says a high user loss rate "can suggest there is low core value for users". These are product problems more than code problems: onboarding, notifications and the reason to come back.

Where do you find Android vitals in Play Console?

1. Open Play Console and go to Monitor and improve → Android vitals → Overview.
2. Pick the date range in the upper right. If there is no data, your app does not have enough data points for the filters you chose.
3. Read the core vitals at the top, then the "Critical issues" section: bad behaviors (over a threshold) and anomalies (sharp changes, such as a jump in ANR rate).
4. Open View details on a metric for its threshold, category benchmarks, peer comparison and trend.
5. Break the data down by app version, Android version, form factor, device model and country.
6. To get email alerts, go to Setup → Notifications or click Manage notifications in the core vitals section. Notifications are currently only available for anomalies, not for bad behaviors.

How long data is kept:

What should you fix first?

Fix in the order that protects visibility fastest:

1. Any core vital over its overall threshold. User-perceived crash rate at 1.09% or more, or user-perceived ANR rate at 0.47% or more. Start with the largest clusters on the Crashes and ANRs page: Google says the more users a cluster affects, the more it adds to the rate.
2. Any device model at 8% or more. Users on that model are steered away. Check the device model breakdown and the Reach and devices overview (Monitor and improve → Reach and devices → Overview) for hardware or Android-version patterns.
3. Anomalies after a release. A sudden rise usually traces to the newest version; compare by app version and consider halting a staged rollout.
4. Metrics close to a threshold. The 28-day window means a problem today keeps counting for weeks, so fix a rising rate before it crosses.
5. DAU/MAU and user loss rate. These need product work, not crash fixes, and take longer to move.
6. Other vitals. Slow start-up (cold start of 5 seconds or more counts as slow), slow and frozen frames, wake-ups and permission denials affect experience and reviews even though they are not core vitals.

After a fix ships, expect the 28-day figures to fall gradually as old bad days leave the window.

How Uptika helps

Uptika does not read your vitals; Play Console does that. What it shows is the effect on the store. The free One-Star Reasons tool sorts recent 1–2 star reviews by reason, so a crash wave shows up as a cluster of complaints. The free Keyword radar reads your Google Play rank for each keyword every day (first page, about 30 apps), and on the Starter plan, Alerts send a message to Slack, Discord, Telegram, a webhook or your phone when your rating or ranks drop. See also the store listing guide. Start free.

Questions

Sources

1. Monitor your app's technical quality with Android vitals (Play Console Help)
2. Get discovered on Google Play search (Play Console Help)