Application Errors
Monitor errors, exceptions, ANRs, and failed requests. Detailed breakdowns by browser, device, OS version, app version, and network conditions.

The Errors tab in Discover Applications helps you identify, analyze, and prioritize errors that affect your users. Error sources and breakdown dimensions depend on whether the data is from a web or mobile SDK.
Error Collection
Web
The JavaScript SDK automatically captures errors from multiple sources:
- Console errors: JavaScript errors logged to the console
- Global errors: Unhandled exceptions and promise rejections
- Reporting Observer: Browser-reported issues like CSP violations
- Network failures: Failed API requests and resource loading errors
Each error includes HTTP details (for network failures), resource timing, session context, and any global attributes you’ve configured.
Control which error sources are enabled:
L9RUM.init({ // ... errors: { console: true, global: true, report: true, network: true, ignorePatterns: [/ResizeObserver/i], beforeSend: (event) => { // Filter or enrich errors if (event.attributes["exception.message"]?.includes("ExpectedNoise")) { return null; // Drop this error } return event; }, },});Explicitly track handled exceptions:
try { await searchProducts(query);} catch (error) { L9RUM.captureError(error, { handled: true, message: "search_query_timeout", query, page: 3, });}Manual captures default to handled: true and pass through the same beforeSend hook as automatic errors.
Mobile
The mobile SDKs capture:
- Unhandled exceptions — uncaught throws on Android (Kotlin/Java), uncaught Swift errors on iOS, unhandled JS errors on React Native, uncaught Dart errors on Flutter
- Promise rejections — unhandled
Promiserejections on React Native - Flutter framework errors — wiring via
FlutterError.onError,PlatformDispatcher.onError, andrunZonedGuarded(see Flutter unhandled error forwarding) - ANRs (Android only) — Application Not Responding events when the main thread is blocked past the configured threshold
- Manual captures —
L9Rum.captureError(e, context)on every platform
See each SDK’s “Capture errors” reference:
- Android — Capture errors
- iOS — Capture errors
- React Native — Capture errors
- Flutter — Capture errors
Accessing Error Monitoring
- Navigate to Discover > Applications in Last9
- Click the Errors tab
- Choose your version and environment from the top filters
- Set your desired time range using the date picker
Dashboard Components
Errors Over Time
Track error frequency throughout your selected time period. The chart shows:
- Error trends and patterns over time
- Spikes that might correlate with deployments or traffic increases
- The option to Include all views to show both error and success rates for context
- Visual distinction between successful pageviews (green) and errors (red)
Top Paths / Top Screens by Error Count
- Web: top URL paths ranked by error count.
- Mobile: top screens (
screen.name) ranked by error count.
Prioritize bug fixes on the entries with the highest error impact.
Error Breakdown Analysis
The dashboard offers multiple breakdown tables. The available breakdown dimensions depend on the platform — the app surfaces a different set for web vs mobile.
Web breakdowns
- Errors by Browser — Chromium, Firefox, Safari, Edge, other. Identifies compatibility issues, polyfill needs, engine-specific behaviors.
- Errors by Platform — Windows, macOS, iOS, Android (browser platform attribute).
- Errors by Screen Size — Large (≥ 1024px), Medium (< 1024px), Small (< 768px). Exposes responsive-layout and mobile-web-only issues.
- Errors by Network Type — WiFi, 4G, 3G, 2G, Unknown. Timeouts and loading failures often cluster on slower connections.
- Errors by Device Type — Mobile, Desktop, Tablet, Unknown.
- Errors by Error Type — grouped by
exception.type. - Errors by City / Country — geographic concentration.
Mobile breakdowns
- Errors by OS Version — isolate OS-specific regressions (e.g. a crash that only reproduces on Android 14).
- Errors by Device Brand — Samsung, Apple, Google, Xiaomi, etc.
- Errors by Device Model — specific model identifier. Often the finest-grained handle on device-specific bugs.
- Errors by App Version — cross-reference spikes with releases.
- Errors by Network Type — WiFi, cellular, offline.
- Errors by Error Type — grouped by
exception.type. For Android, ANRs surface here distinctly from exceptions. - Errors by City / Country — geographic concentration.
Detailed Error Investigation

Individual Error Analysis
Click on any error entry to view detailed information:
Each error provides:
- Timestamp: when the error occurred
- View ID: unique identifier for the view (page view on web, screen view on mobile)
- Path / Screen: URL where the error happened (web) or screen name (mobile)
- Browser / OS: user’s browser (web) or OS name + version (mobile)
- Screen Size / Device Model: device screen category (web) or device model (mobile)
- Network Type: connection type when error occurred
- App Version (mobile): release version the user was on
Exception Details
- Exception timing: How long after page start the error occurred
- Full stack trace: Complete error stack with file names and line numbers
- Error context: Surrounding code and variable states when available
- Trace link: Click “Trace” to view the complete user session
This detailed information helps developers identify the exact source of errors, understand the user context when errors occur, reproduce issues by following the user’s journey, and prioritize fixes based on error frequency and impact.
Custom Events in Error Context
When you open the error details sidepanel, Last9 also displays any custom events that occurred within the same session view — not just the error itself. This lets you reconstruct what the user was doing immediately before and after the error fired.
Custom events are tracked via L9RUM.addEvent() on web and L9Rum.addEvent() on mobile, and are distinct from errors — they carry no exception or stack trace, but they do carry the attributes you attach. Examples include button clicks, checkout steps, feature flag evaluations, or any business action you want to correlate with failures.
L9RUM.addEvent("checkout_attempted", { step: "payment", plan: "pro", amount: 99,});How custom events differ from errors
Errors (captureError) | Custom events (addEvent) | |
|---|---|---|
| Purpose | Capture exceptions and failures | Track user actions and business events |
| Stack trace | Yes | No |
| Appears in error count | Yes | No |
| Shown in error sidepanel | As the primary event | As contextual events within the same view |
Passes beforeSend hook | Yes | No |
Tracking custom events
Call L9RUM.addEvent() with a name and an optional attributes object at any point in your application:
// Track a business actionL9RUM.addEvent("payment_method_selected", { type: "credit_card" });
// Track a feature interactionL9RUM.addEvent("search_performed", { query_length: query.length, result_count: results.length,});
// Track a navigation stepL9RUM.addEvent("onboarding_step_completed", { step: 3, step_name: "invite_team",});Events inherit session and view context automatically. Any attributes set via L9RUM.spanAttributes() are also attached, so you do not need to repeat user or organization context on each event call.
Filtering and Grouping
Same filtering capabilities as the Performance tab:
- Path / Screen filtering: focus on specific pages (web) or screens (mobile)
- Attribute filtering: filter by browser/OS, device, network, app version, or custom attributes
- Time-based filtering: analyze errors within specific time windows
- Environment filtering: compare error rates across deployments
Best Practices
- Monitor Error Trends: Watch for error spikes after deployments
- Focus on High-Impact Errors: Prioritize errors affecting many users or critical paths
- Correlate with Performance: Slow pages often have higher error rates
- Browser Testing: Pay attention to browser-specific error patterns
- Mobile-First Debugging: Mobile users often experience unique error conditions
- Set Error Budgets: Define acceptable error rates and alert when exceeded
- Regular Review: Check error patterns weekly to catch regressions early
Troubleshooting
- No errors showing? Confirm error toggles in the
errorsconfiguration are enabled andsampleRateis appropriate for your traffic volume. - Manual captures missing context? The SDK automatically includes session and user context. Additional attributes passed to
captureError()are merged with SDK-provided fields. - Network failures missing? Check browser DevTools for CORS issues—failed preflights prevent the SDK from capturing response details.
- Custom events not appearing in sidepanel? Custom events are scoped to the same view as the error. If
L9RUM.addEvent()is called outside an active view (for example, before the first page navigation completes), the event may not be associated with a view and will not appear. Ensure SDK initialization is complete before callingaddEvent().
Please get in touch with us on Discord or Email if you have any questions.