Mobile App Error Monitoring: Complete Guide 2026
Crash reporting only catches errors that kill your app. The silent errors — failed API calls, broken flows, unhandled edge cases — are often causing more user churn than crashes. This guide covers comprehensive mobile error monitoring for both fatal and non-fatal errors.
In this guide
- 1. Error Monitoring vs Crash Reporting: What's the Difference?
- 2. Non-Fatal Errors: The Silent UX Killers
- 3. Error Types to Monitor in Mobile Apps
- 4. Setup: Capturing All Error Types with Logtrics
- 5. Error Grouping, Deduplication & Prioritisation
- 6. Alerting for Non-Fatal Errors
- 7. Dashboard: Error Rate, Error-Free Sessions
- 8. FAQ
1. Error Monitoring vs Crash Reporting: What's the Difference?
| Aspect | Crash Reporting | Error Monitoring |
|---|---|---|
| Scope | Fatal errors only | Fatal + non-fatal errors |
| App still running | No | Yes (for non-fatal) |
| User impact visible | Only if they report it | Yes — UX degradation tracked |
| API failure detection | Only if it crashes | Every failure |
| Business impact | Lost session | Lost conversion, churn |
Think of crash reporting as an ambulance — it responds to catastrophic events. Error monitoring is more like continuous health monitoring — it catches problems before they become emergencies.
2. Non-Fatal Errors: The Silent UX Killers
Non-fatal errors don't crash your app — they just make it quietly broken. Users experience degraded UX, give up, and churn. You never know why.
API Failures
Your app shows an empty cart or "Something went wrong" because the backend returned a 500. The user doesn't see a crash — they see a broken feature.
Data Parsing Errors
A JSON field changes type in the backend. Your iOS app falls back to a default value silently. A key feature shows wrong data to all users for 3 days.
Image / Asset Load Failures
Product images fail to load during a sale event because the CDN is overloaded. Users see broken images. Conversion drops 40%. No crash reported.
Payment / Checkout Errors
A payment validation error only shows a generic "Try again" message. You have no idea how many users hit this until revenue drops and someone files a bug.
Key insight: Non-fatal errors often have higher business impact than crashes. A crash affects one session. A broken checkout flow silently blocks conversions for every user who hits it.
3. Error Types to Monitor in Mobile Apps
Fatal Crashes
Unhandled exceptions that terminate the app process. These are captured automatically by Logtrics — you don't need to add any code.
Caught Exceptions
Errors caught in try/catch blocks. You must explicitly report these with Logtrics.recordError() — they won't be captured automatically since the app didn't crash.
Network / API Errors
HTTP 4xx/5xx responses, timeouts, and connection failures. Enable Logtrics network monitoring to capture all API errors automatically with request/response context.
Business Logic Errors
Custom error conditions: stock unavailable, payment declined, validation failure. Log these as structured error events with business-specific context (product ID, cart value, user plan).
Performance Errors
Operations that exceed acceptable thresholds: API calls taking >3s, screen renders taking >1s, database queries taking >500ms. These degrade UX without crashing.
4. Setup: Capturing All Error Types with Logtrics
iOS (Swift) — Non-Fatal Error Reporting
do {
let order = try await orderService.fetchOrders(userId: user.id)
await updateUI(with: order)
} catch let error as NetworkError {
// Report non-fatal — app continues running
Logtrics.recordError(error, context: [
"screen": "OrderHistory",
"userId": user.id,
"endpoint": "/api/orders",
"severity": "error"
])
showEmptyState(message: "Couldn't load orders. Please try again.")
}Android (Kotlin) — Non-Fatal Error Reporting
try {
val result = paymentRepository.charge(amount, cardToken)
onPaymentSuccess(result)
} catch (e: PaymentException) {
Logtrics.recordError(e, mapOf(
"errorCode" to e.code,
"amount" to amount,
"currency" to "USD",
"screen" to "Checkout"
))
showPaymentError(e.userFacingMessage)
}React Native — Non-Fatal Error Reporting
try {
const profile = await api.fetchUserProfile(userId);
setProfile(profile);
} catch (error) {
Logtrics.recordError(error, {
screen: 'ProfileScreen',
userId,
action: 'fetch_profile',
severity: 'error'
});
setProfileError(true);
}5. Error Grouping, Deduplication & Prioritisation
Without grouping, 10,000 occurrences of the same error appear as 10,000 separate events in your dashboard. Logtrics groups errors by:
Stack Trace Fingerprint
Same error at the same code location = same group
User Impact Score
Unique affected users × session frequency × severity weight
Trend Detection
New errors, regression errors, and improving errors flagged automatically
This means your error queue shows the 5 errors that matter most — not a wall of 10,000 events to sort through.
6. Alerting for Non-Fatal Errors
Non-fatal errors need different alert thresholds than crashes. A single crash is always worth an alert. A single non-fatal error may be noise. Configure alert rules based on:
Error rate threshold
Alert when a specific error affects >1% of sessions in a 1-hour window. Example: "CartService failed to load" affecting 2% of sessions = alert immediately.
Business-critical paths
Alert on any error in checkout, login, or onboarding — regardless of rate. A single payment error should never go unnoticed.
New error type
Alert immediately when a non-fatal error type is seen for the first time. New errors after a deploy = potential regression.
7. Dashboard: Error Rate & Error-Free Sessions
Track two parallel metrics to measure your overall error health:
Crash-Free Session Rate
Sessions with zero fatal crashes / total sessions. Target: 99.5%+. This is the metric Google Play and the App Store care about.
Error-Free Session Rate
Sessions with zero errors (fatal or non-fatal) / total sessions. This is your true UX quality metric. Top apps target 97%+.
An app can have 99.8% crash-free sessions but 85% error-free sessions — meaning 15% of all sessions have at least one broken experience. Error monitoring reveals the gap.
FAQ
What is the difference between error monitoring and crash reporting?
Crash reporting captures only fatal errors that terminate the app. Error monitoring is broader — it captures non-fatal errors (caught exceptions, API failures, business logic errors) that degrade UX without crashing. You need both for full app health visibility.
What are non-fatal errors in mobile apps?
Caught exceptions and failure states that don't crash the app: failed API calls, image load failures, payment declines, data parsing failures, empty states from backend bugs. These silently hurt retention and conversion.
Should I monitor every error or just crashes?
Monitor both, but with different rules. Crashes = immediate alert always. Non-fatal errors = alert when they cross a user-impact threshold (e.g., >1% of sessions). Don't alert on individual non-fatal errors or you'll face alert fatigue.
How do I capture non-fatal errors in iOS?
Use Logtrics.recordError(error, context: [...]) inside your catch blocks. This sends the error and your custom context to the dashboard without crashing the app or affecting the user experience.
Monitor Every Error, Not Just Crashes
Logtrics captures fatal crashes AND non-fatal errors, with AI grouping, real-time alerts, and a dashboard that shows you what actually matters. Start in 5 minutes.