Mobile App Monitoring: Crashlytics, ANR, Performance
In production, every minute of downtime means lost users and revenue. A crash-free rate of 99.2% sounds decent until you calculate: with 100,000 DAU, that's 800 crashes per day. Without monitoring tools, the team learns about issues from App Store reviews — hours later, when hundreds of users have already encountered the error. We solve this: we set up a full monitoring cycle — from Crashlytics integration to Telegram alerts. Our experience: 5+ years in mobile development, we've delivered 50+ releases with guaranteed stability. Contact us for a free audit of your app's current state.
Why mobile app monitoring is essential
Every percentage point drop in crash-free rate costs tens of thousands of dollars in lost revenue due to user churn and reduced store ratings. The investment in monitoring pays off in 2-3 months. According to Google, an app with an ANR rate above 0.47% loses up to 20% of users. By configuring alerts, you reduce crash response time from 4 hours to 10 minutes — this preserves revenue and reputation.
Saving from monitoring implementation can reach 30% of the support budget, and the average cost of an incident is tens of thousands of dollars. Timely alert setup allows quick problem localization and loss minimization. Order a stability audit and get recommendations.
Which metrics are critical in production? — mobile app monitoring
Crashes and errors
The main tool is Firebase Crashlytics. It automatically intercepts fatal and non-fatal exceptions, groups them by stack trace, and shows affected users and sessions. Key metrics for daily monitoring:
- Crash-free users (not sessions) — the real picture by users
- Velocity alerts — Crashlytics can send a notification when a new crash affects N% of sessions per hour
- Regression tracking — a crash was fixed, but reappears in a new version
For NDK/C++ components, you need to separately configure nativeSymbolUploadEnabled = true and upload .so symbols via Crashlytics CLI.
ANR and hangs (Android)
Google Play Console → Android Vitals → ANR rate. Google's threshold — 0.47% ANR-rate; above that, the app is marked as problematic and is demoted in search. ANR on the main thread usually means blocking IO or a synchronous database query in onCreate.
StrictMode in debug builds helps catch such issues before production:
if (BuildConfig.DEBUG) { StrictMode.setThreadPolicy( StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectNetwork() .penaltyLog() .build() ) } Performance (iOS MetricKit)
MetricKit since iOS 14 delivers aggregated diagnostic data: hang rate, crash rate, disk writes, launch time. Data arrives once a day in didReceive(_ payloads: [MXMetricPayload]). For launch time monitoring, it is critical to track applicationLaunchMetrics.histogrammedTimeToFirstDraw — a degradation of 200ms already impacts retention. More details in Apple documentation (Developer Documentation).
Non-standard events
Firebase Crashlytics allows logging non-fatal errors manually — important for business-critical flows:
// iOS: log payment error as non-fatal Crashlytics.crashlytics().record(error: paymentError) Crashlytics.crashlytics().log("Payment failed at step: \(step)") // Android FirebaseCrashlytics.getInstance().recordException(exception) FirebaseCrashlytics.getInstance().log("Checkout step: $step") This way, "soft" errors appear in Crashlytics — the user didn't see a crash, but the transaction failed.
How to set up alerts for quick response
We set up notifications in Slack or Telegram via Crashlytics webhooks or Firebase Extensions. Minimum set of alerts:
| Event | Threshold | Channel |
|---|---|---|
| New crash in release build | Any | #crashes-mobile |
| Crash-free rate dropped | < 99.5% per hour | #incidents |
| ANR rate (Android) | > 0.3% | #android-ops |
| Velocity alert | > 0.1% sessions in 30 min | #incidents (pager) |
Alerting via Slack is 3 times faster than reacting to store reviews — you learn about a problem within a minute.
What's included in a turnkey monitoring setup
As part of the service, we provide:
- Crashlytics integration and velocity alerts configuration
- Connecting alerts to Slack/Telegram
- Android Vitals and MetricKit setup
- Documentation on metrics and incident response
- Team training: how to read reports and troubleshoot crashes
- Access to monitoring tools
We guarantee stable operation: after setup, you achieve crash-free rate of no less than 99.9% at the target level.
| Metric | Target value |
|---|---|
| Crash-free users | ≥ 99.5% |
| ANR rate (Android) | < 0.3% |
| Launch time (iOS) | < 2 sec |
Checklist: what to check before monitoring setup
- Ensure the project has the latest Crashlytics SDK.
- Check that ProGuard/R8 is configured for Android — to avoid stripping logs.
- For iOS: configure Bitcode and crash symbolication.
- Define the list of business-critical flows for non-fatal logging.
- Agree on notification channels (Slack/Telegram) and responsible persons.
Work process
- Analytics — examine current tools and code for logging
- Design — define key metrics and thresholds
- Implementation — integrate SDK, configure non-fatal logging
- Testing — simulate crashes and verify alerts
- Deployment — roll out to staging, then production
Timeline estimates
Initial full monitoring setup — 1 to 3 days depending on project complexity. Ongoing monitoring and weekly reports — discussed individually. Contact us to evaluate your project — we will prepare an accurate estimate and timeline.
Case study: One of our clients experienced a crash-free rate drop to 99.0% after a new release. Thanks to velocity alerts, we noticed the problem within 10 minutes and identified the cause in an hour — a memory leak in UICollectionView. Users didn't even have time to leave negative reviews.
Get a consultation — we will analyze your app's current state for free and propose a monitoring plan. Order a stability audit now.