Network Error Monitoring in Mobile Apps: Setting Up Sentry
Picture this: 3:00 AM, backend responds with 502. 8% of users see an empty screen, some of them uninstall the app. We deal with this every day—production without network error monitoring loses users. With Sentry, we intercept such scenarios early, group errors by fingerprint, and configure alerts to never miss a failure.
Network errors vary: from connection loss to response parsing issues. Each category requires its own monitoring strategy. Below is a priority-based classification derived from experience with dozens of projects.
| Error Type | Example | Priority |
|---|---|---|
| Connectivity | Network request failed, timeout |
High—user cannot work |
| 4xx client | 401, 403, 404, 422 | Medium—often expected |
| 5xx server | 500, 502, 503, 504 | High—backend issue |
| Parse error | JSON decode failure | High—breaking API change |
| SSL/TLS | Certificate pinning failure | Critical—possible attack |
Why Sentry Over Custom Logging?
Custom logging often creates thousands of duplicate tickets. Sentry groups them by fingerprint—cutting analysis time by 5–10x. Sentry also provides context: device, OS version, request traces. According to Sentry documentation, proper grouping reduces incidents by 70%. We have been using Sentry for years—it's a proven production solution. Over the years, we have set up monitoring for dozens of projects, from fintech to e-commerce.
How to Intercept Network Requests in React Native?
@sentry/react-native automatically patches fetch and XMLHttpRequest. By default, it includes Performance traces but does not log errors automatically. Here is the configuration:
import * as Sentry from '@sentry/react-native'; Sentry.init({ dsn: 'https://[email protected]/yyy', tracesSampleRate: 0.1, // 10% of requests traced for Performance integrations: [ new Sentry.ReactNativeTracing({ traceFetch: true, traceXHR: true, // Do not include sensitive endpoints in traces tracingOrigins: ['api.yourapp.com', 'cdn.yourapp.com'], }), ], }); For explicit network error logging, wrap fetch:
export async function monitoredFetch( url: string, options?: RequestInit ): Promise<Response> { const startTime = Date.now(); try { const response = await fetch(url, options); const duration = Date.now() - startTime; if (!response.ok) { Sentry.captureMessage(`HTTP ${response.status}: ${url}`, { level: response.status >= 500 ? 'error' : 'warning', extra: { status: response.status, duration, method: options?.method ?? 'GET', endpoint: new URL(url).pathname, }, fingerprint: [`http-${response.status}`, new URL(url).pathname], }); } return response; } catch (error) { Sentry.captureException(error, { extra: { url, duration: Date.now() - startTime }, tags: { error_type: 'network_connectivity' }, }); throw error; } } fingerprint is critical. Without it, Sentry creates a separate issue for each URL with an error. With fingerprint: ['http-500', '/api/orders'], all 500 errors on /api/orders are grouped into one issue.
How to Configure Fingerprint for Grouping?
In the code above, we use the response status and endpoint path. To group by a different criterion, change the array. For example, for authentication errors: ['auth-4xx'].
Breadcrumbs: Context Before the Error
Breadcrumbs show what happened before the network error: which screens the user visited, what actions they performed. By default, the last 100 breadcrumbs are stored—enough for long sessions. Here is how to add a breadcrumb on navigation:
// Add breadcrumb on navigation navigation.addListener('state', (e) => { Sentry.addBreadcrumb({ category: 'navigation', message: `Navigate to ${e.data.state.routes[e.data.state.index].name}`, level: 'info', }); }); Thanks to breadcrumbs, problem localization time drops from hours to minutes: you see not just an error, but the sequence of user actions.
How to Separate Offline Errors from Server Errors?
Offline errors must be distinguished from server errors. A user on the subway is not a backend problem:
import NetInfo from '@react-native-community/netinfo'; let isConnected = true; NetInfo.addEventListener(state => { isConnected = state.isConnected ?? true; }); // In monitoredFetch, inside catch: if (!isConnected) { // Do not send to Sentry—this is expected offline throw new OfflineError('No network connection'); } // Otherwise—real error, log it Sentry.captureException(error, { tags: { connectivity: 'online' } }); Comparison of Alerting Approaches
| Method | Sensitivity | Response Time |
|---|---|---|
| Manual log monitoring | Low | Hours |
| Sentry Alerts with threshold | High | Minutes |
How to Set Up Alerts in Sentry?
Sentry Alerts based on condition: count(event) > 50 per 5min for http-500 → Slack/PagerDuty. Error rate above baseline → alert. For production, this should run 24/7. Here is a step-by-step guide:
- Open Alerts → Create Alert.
- Choose type: Issues (error count).
- Set criterion: filter by level (
error), tags (endpoint). - Specify threshold: e.g., 50 events in 5 minutes.
- Configure channel: Slack, PagerDuty, email.
- Set silence interval (to avoid spam).
Done. Alerts will automatically notify the team about error spikes.
What’s Included in Turnkey Setup?
We guarantee correct monitoring configuration. The scope includes:
- Sentry integration into the app (any stack: React Native, Flutter, native).
- Fingerprint setup for all endpoints.
- Offline detection and breadcrumbs added.
- Alert rule development and integration with your messenger.
- Developer documentation.
- Team training (1–2 calls).
- Support for one month after launch.
We have been configuring monitoring for production apps for years. Among our clients are fintech, e-commerce, and SaaS companies. We will assess your project for free—contact us. Reach out for a consultation or order the setup now.
Assessment
Sentry setup with network request monitoring, fingerprinting, offline detection, and alerts: 1–2 weeks. Cost is calculated individually based on complexity and stack. Want to protect your app? Fill out the feedback form—we’ll get back to you within a day.







