Application Real-Time Monitoring Service:exception tracking

Detection Methods

The SDK detects exceptions through:

• Automatic capture - Monitors network request failures, crash signals, main thread blocking, and frame rate drops without code changes.

• Manual reporting - Reports exceptions caught in your code (e.g., try-catch blocks) via the SDK's custom exception API for non-fatal errors or business-specific failures.

Stack Trace Collection and Symbolication

When an exception occurs, the SDK captures the call stack. Symbolication requirements vary by platform:

• Web and Mini-Programs - Collects JavaScript error stack traces. For minified code, the service uses your SourceMap files to de-obfuscate stacks, mapping compressed positions to original file names, method names, and line numbers.

• Mobile Apps (iOS/Android) - Captures full call stacks from the crash thread and all threads, plus binary image metadata (module names, architectures, UUIDs, load addresses). The service uses your symbol files (iOS dSYM / Android Mapping) to symbolicate memory addresses into readable class names, method names, and line numbers.

The goal: transform raw stacks into human-readable source locations for direct code inspection.

Contextual Enrichment

Every exception event includes:

• Session ID - Links to the complete user session for action replay.

• Page information - Page name and ID where the error occurred.

• User identifiers - User ID, username, or custom identifiers.

• Device and environment - Device model, OS version, network type, app version.

This context provides the full user journey—not just an isolated stack trace.

Exception Processing Flow

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Exception   │───▶│  Signal      │───▶│  Stack       │
│  Occurs      │    │  Capture     │    │  Collection  │
└──────────────┘    └──────────────┘    └──────┬───────┘
                                               │
                                               ▼
┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│  Console     │◀───│  Server-side │◀───│  Attach      │
│  Root Cause  │    │  Symbolication│   │  Context     │
│  Analysis    │    │  & Restore   │    │  & Report    │
└──────────────┘    └──────────────┘    └──────────────┘

Note: Crashes terminate the app, so crash data is reported on the next app launch.

Network Request Errors

The SDK intercepts network requests. When requests fail, time out, or return HTTP errors, it logs errors with detailed timing breakdowns to distinguish client-side network issues from server-side problems.

Timing breakdowns help identify issues:

• High DNS timing - DNS resolver instability or domain configuration issue

• High TCP/TLS timing - Network path instability or certificate issue

• High TTFB - Server processing delay

• HTTP 4xx/5xx status - Server-side error requiring backend investigation

Slow Page Loads

The SDK measures page load time for every view. When load time exceeds the configured threshold, the page is flagged as slow.

Note: Configure the slow load threshold remotely via the console.

App Crashes

The SDK captures crashes during app execution, including uncaught exceptions and system-level errors. Crash data is reported on next app launch.

Supported crash types:

Captured attributes:

ANR (Application Not Responding)

The SDK detects when the main thread is blocked for an extended period. When blocking exceeds the threshold, an ANR event is logged with the main thread stack trace.

Common ANR causes:

• Main thread performing synchronous I/O operations (file reads/writes, database queries)

• Main thread executing heavy computation or large data processing

• Deadlock or inter-thread waiting

• Synchronous network requests blocking the main thread

Lag (Long Task)

The SDK monitors main thread execution and rendering frame rate. When it detects long-running blocking or frame rate drops, it records lag events.

Detected lag types:

• Main Thread Blocking - Tasks exceeding the execution time threshold

• Frame Rate Drop (FPS Drop) - Rendering frame rate below threshold, causing UI stuttering

• Disk I/O Blocking - Disk read/write operations on the main thread

• CPU Overload - High CPU usage causing performance degradation

Stack Symbolication

Raw stacks require symbolication to become actionable:

• Web apps - Upload SourceMap files to map minified code positions to original source file names, method names, and line/column numbers.

• Mobile apps - Upload symbol files (iOS dSYM / Android Mapping) to convert memory addresses to readable class names, method names, and line numbers.

After symbolication:

• Identify the class and method - See exactly which class and method threw the error.

• Jump to the source line - Get the precise file name and line number.

Symbolicated stacks let you jump directly to the problematic code.

Session Replay

Every exception links to a Session ID and page context. From the console, view the user's complete action sequence before the error:

1. Which pages the user visited in order

2. What actions they performed on each page (taps, scrolls)

3. Which network requests were triggered and whether they succeeded

4. Whether other errors or lag occurred before the final exception

This context provides the full scenario—not just an isolated stack trace.

Multi-Dimensional Aggregation

The console automatically groups similar exceptions. Analyze impact and distribution patterns across dimensions:

• Device - Errors concentrated on specific device models or OS versions

• Version - Error introduced in a particular release

• Page - Errors concentrated on specific pages

• Time - Error spikes during specific time windows

Diagnosing Crash Root Causes

Production crash rate suddenly spikes. Check the crash list in the console to identify new crash types. View the symbolicated stack to pinpoint the exact code line. Review session replays—crashes consistently occur after users perform a specific action sequence, confirming a logic bug in the latest release.

Troubleshooting Network Failures

User reports "data failed to load." Use the user ID to find the session. Locate the failed network request in the session trace. Check timing: DNS and TCP connection are normal, but TTFB exceeds 10 seconds and returns 504—identifying a backend timeout for escalation to the server team.

Optimizing Lag Performance

User reports "list scrolling is choppy." Check lag events—many frame rate drops concentrate on the product list page. Review the lag stack trace—the main thread performs synchronous image decoding during scroll. Move image decoding to a background thread, resolving the lag.