Why Error Monitoring Is Non-Negotiable
You cannot ask your users to open the console and send you logs. Mobile apps run on millions of devices with different OS versions, hardware configurations, and network conditions. When something breaks, automated error monitoring is the only way you know about it.
A 1% crash rate may sound small, but if your app has 100,000 daily users, that is 1,000 people experiencing crashes every single day.
Crash Reporting vs Error Monitoring vs Logging
- Crash reporting captures fatal errors that terminate the app (unhandled exceptions, segfaults, ANRs)
- Error monitoring captures both fatal and non-fatal errors, including handled exceptions and API failures
- Logging records informational events and breadcrumbs that help you understand context around errors
A complete observability stack includes all three.
Major Platforms
Firebase Crashlytics
Free with no limits. Automatic crash detection, real-time alerts with velocity tracking, breadcrumb logs, and integration with Google Analytics.
Sentry
Comprehensive error monitoring with session replay for mobile, release health tracking, and source map/dSYM support for readable stack traces. Free tier: 5K errors/month, paid starts at $26/month.
Datadog
Full-stack observability with Real User Monitoring (RUM) for mobile, crash reporting, network request tracking, and backend log correlation. Starts at $15/host/month.
Bugsnag
Mobile-focused with automatic crash and ANR detection, stability score tracking, and smart error grouping. Free tier: 7,500 events/month.
What to Capture
Every error report should include:
- Stack trace - The exact code path that led to the error
- Device info - Model, OS version, available memory, disk space
- App info - App version, build number, environment
- User context - User ID (not PII), account type, subscription status
- Breadcrumbs - Sequence of user actions leading to the error
- Custom tags - Feature flags, A/B test variants, network type
Symbolication
Raw crash logs contain memory addresses and minified code. Upload debug symbols for every release:
- iOS - Upload dSYM files
- Android - Upload ProGuard/R8 mapping files
- React Native - Upload JavaScript source maps
- Flutter - Upload Dart symbol files
Automate symbol upload in your CI/CD pipeline. Missing symbols make crash reports unreadable.
Alerting Strategy
| Severity | Condition | Alert Channel | Response Time |
|---|---|---|---|
| Critical | Crash rate exceeds 2% | PagerDuty/phone call | Immediate |
| High | New crash affecting 100+ users | Slack + email | Within 1 hour |
| Medium | Non-fatal error spike (3x baseline) | Slack | Within 1 day |
| Low | Individual error reports | Dashboard only | Next sprint |
Track your crash-free session rate as a primary health metric. 99.5%+ is the industry standard. Below 98% requires immediate attention.
Triage Best Practices
When a new error appears, assess with these questions:
- How many users are affected? 5% is more urgent than 0.01%
- Is it increasing? A rapidly growing error needs faster response
- Which app version? If only in the latest release, consider an emergency update
- Is there a workaround? Can you disable the feature via remote config?
- What is the user impact? A payment screen crash is more critical than a settings crash
Non-Fatal Error Tracking
Do not just track crashes. Capture handled errors that degrade the experience: API 5xx errors, JSON parsing failures, image loading failures, auth token refresh failures, and database write failures. These "silent failures" often affect more users than crashes.