Kotzilla Console 4.5.0 introduces structured crash stack traces with frame-origin labeling, stricter ANR detection at 2 seconds, and health thresholds aligned with Google Play's own quality benchmarks, giving Android and KMP teams a single source of truth for production app health.
Most mobile observability tools define their own thresholds for crash-free rates and ANR-free rates. The problem: those thresholds rarely align with what actually matters for app distribution. Google Play has its own health benchmarks. If your app falls below them, it risks lower store visibility, warnings, or removal, regardless of what your internal dashboard says is "acceptable."
The gap between internal metrics and Google Play standards creates a false sense of stability. A team might consider a 99.2% crash-free rate healthy by their own baseline, while Google Play is already flagging their app.
Kotzilla Console 4.5.0 closes that gap by aligning Dashboard health thresholds directly with Google Play targets, and adding stricter ANR detection that catches real-world freezes before they become store-level incidents.
Android app health monitoring is the practice of tracking key stability metrics (crash-free rate, ANR-free rate, and slow component rate) across production sessions to detect regressions, benchmark against platform standards, and prioritize fixes before they affect store performance or user retention.
Effective app health monitoring requires:
Kotzilla 4.5.0 addresses all three.
Raw crash stack traces in Android and KMP apps are notoriously hard to read. A typical trace mixes Kotlin frames, Java frames, Objective-C frames (on iOS), and OS-level system frames, all in the same list, with no clear indication of which layer originated the crash. Developers spend time manually identifying which frames are theirs versus platform noise.
Kotzilla Console 4.5.0 normalizes crash stack traces and labels each frame with its origin:
On Android:
KT — Kotlin frameJava — Java frameOn iOS (Kotlin Multiplatform):
KT — Kotlin/Native frameObjC — Objective-C frameSystem — OS-level frameThis labeling makes it immediately clear whether a crash originates in your Kotlin business logic, a Java dependency, the platform bridge (Objective-C on iOS), or the operating system itself.
For Kotlin Multiplatform apps, crashes on iOS can originate in Kotlin/Native code, the Objective-C interop layer, or native iOS frameworks. Without frame-origin labeling, triaging an iOS crash from a KMP codebase requires manually cross-referencing the trace with your module structure.
With Kotzilla's labeled stack traces, a KMP team can determine in seconds whether a crash is in shared Kotlin code (and therefore affects all platforms) or in platform-specific glue (and therefore scoped to one target).
| Status | Range | Meaning |
|---|---|---|
| 🟢 Green | ≥ 99.50% | Healthy, above Google Play targets |
| 🟡 Orange | 99.00% – 99.49% | Below target, needs attention |
| 🔴 Red | < 99.00% | Google Play flags apps at 98.91% |
| Status | Range | Meaning |
|---|---|---|
| 🟢 Green | ≥ 99.53% | Above the Google Play threshold |
| 🟡 Orange | 99.00% – 99.52% | Below the Google Play flag |
| 🔴 Red | < 99.00% | Serious problem |
| Status | Range | Meaning |
|---|---|---|
| 🟢 Green | ≥ 90.00% | Clean architecture |
| 🟡 Orange | 75.00% – 89.99% | Optimization needed |
| 🔴 Red | < 75.00% | Major dependency injection performance issues |
The Slow Component Free Rate is unique to Kotzilla. Because Kotzilla is built on the Koin dependency injection framework, it can measure at a granular level how often DI resolutions are slow, something generic APM tools cannot surface. This metric directly reflects the quality of your app's dependency injection architecture under production load.
An Application Not Responding (ANR) occurs when an Android app's main thread is blocked and cannot process user input or draw frames for a sustained period. Google Play defines ANRs at 5 seconds for most interactions, but user experience degrades well before that threshold.
Kotzilla 4.5.0 flags ANRs at 2 seconds, down from the previous 5-second threshold. This change reflects two realities:
Combined with Google Play-aligned ANR-free rate thresholds, this gives teams both an early detection signal and a clear benchmark for what "acceptable" looks like in the context of store performance.
Console 4.5.0 also introduces a clearer app status system on the homepage. Each app is now classified into one of four states:
The default observation window is 14 days, and the dashboard overview is scoped to the selected app version and timestamp. Session counts are consistent across all platform views.
This classification replaces ambiguous aggregate metrics with an actionable triage view, useful both for individual developers managing a single app and for teams maintaining multiple apps in a portfolio.
What crash-free rate does Google Play use to flag apps?
Google Play flags apps with a crash-free rate below 98.91%. Kotzilla's orange threshold starts at 99.00%, giving you a warning before you reach the store's flag level.
Why does Kotzilla flag ANRs at 2 seconds when Google Play uses 5 seconds?
Google Play's 5-second ANR definition is a store-enforcement threshold, not a user experience benchmark. Kotzilla flags at 2 seconds to give teams an early warning before ANRs escalate to store-visible incidents.
What is the Slow Component Free Rate?
The Slow Component Free Rate measures the percentage of sessions where no dependency injection resolution (via Koin) is flagged as slow. It is unique to Kotzilla and reflects DI architecture quality under real production load. A rate below 75% indicates major performance issues in the app's dependency graph.
Does Kotzilla's crash stack trace labeling work for iOS apps built with KMP?
Yes. On iOS, frames are labeled as KT (Kotlin/Native), ObjC (Objective-C interop), or System (OS-level), making it straightforward to identify whether a crash originates in shared Kotlin code or platform-specific layers.
How does the 14-day default window affect health metrics?
The 14-day window provides enough session volume for statistically meaningful health rates while keeping the data actionable. It is scoped per app version and timestamp, so version-specific regressions don't get masked by older, healthy sessions.
What does "Quiet" status mean on the homepage?
Quiet means the app is correctly configured and reporting to Kotzilla, but no sessions have been analyzed in the last 14 days. This typically means the app version is no longer in active use or the SDK is not being triggered in the current build being distributed.
Kotzilla Console 4.5.0 makes production app health monitoring actionable by grounding it in the same standards that actually govern app distribution. Google Play-aligned thresholds, 2-second ANR detection, and frame-origin-labeled crash stack traces give Android and KMP teams a clear, honest picture of their app's stability, and the diagnostic detail to act on it quickly.
For the full SDK changelog and setup instructions, see the Kotzilla documentation.