You will find out about most bugs from your monitoring tool, not your users. Set it up that way

Users who report bugs are a small, self-selected group. Most people who hit a crash simply close the app, and a large share never open it again. Crash and performance monitoring is how you find out about the other 95% — the ones who churned silently instead of filing a report.

What to instrument, in order of priority

• Crash and exception reporting — every unhandled error, with stack trace, device model, OS version and the user action that preceded it
• ANR (Application Not Responding) and freeze detection on Android, and equivalent hang detection on iOS
• API latency and error rates from the client's perspective, not just server-side logs — the client sees timeouts the server never records
• Cold start and screen transition times, since slow startup is a top reason for immediate uninstalls
• Session replay or breadcrumb trails for the minutes leading up to a crash, so the report includes context, not just a stack trace

Tools worth evaluating

Firebase Crashlytics is the default for most teams already on Google's stack and is free at reasonable volume. Sentry covers crash reporting plus performance tracing across mobile and backend in one dashboard, which matters when a mobile crash traces back to a backend regression. Datadog and New Relic are stronger for teams that already run backend APM and want mobile folded into the same alerting pipeline rather than a separate tool.

Alerting that doesn't train the team to ignore it

The fastest way to make monitoring useless is to alert on every exception and let the channel fill with noise until nobody reads it. Set thresholds: alert immediately on a new crash type affecting more than a defined percentage of sessions, or on a crash-free-session rate dropping below a set baseline (many teams target 99.5%+). Route lower-severity issues to a daily digest instead of a real-time ping.

• Alert in real time on: new crash affecting >1% of sessions, crash-free rate dropping below baseline, API error rate spiking
• Digest daily: minor exceptions, slow-but-not-failing requests, one-off device-specific issues
• Review weekly: top crashes by user impact, not just by frequency — one crash hitting 50 power users can matter more than one hitting 500 new installs

Set it up before launch, not after the first bad review

Monitoring added after a crisis captures the next crisis, not the one that already cost you users. Wire crash and performance reporting into the build before the first TestFlight or Play internal test track goes out — it costs an afternoon during development and nothing meaningful in runtime overhead, and it means the first real bug report you get is from a dashboard, not a one-star review.

Sources