Deep Inspector Beyond Crashes: Health Dashboard, ANR Detection, and Real-Time Notifications

Post #04 showed you how Deep Inspector captures crashes. But crashes are only one of seven issue types Deep Inspector detects.

The app that freezes for 8 seconds but doesn’t crash? Deep Inspector catches that. The app that triggers 50 garbage collections per second? That too. The app whose frames stutter every time you scroll? Detected, logged, and scored.

Deep Inspector is a lightweight APM running entirely on your device. No SDK integration, no cloud dependency, no instrumentation. Just logcat analysis with real-time pattern matching, a health dashboard, and instant notifications. This post covers everything beyond crash capture.

Beyond Crashes: 7 Issue Types

Every log entry that flows through the Health Monitor is analyzed by a real-time detection engine. It uses regex pattern matching and stateful tracking to classify issues into seven types, each with a severity level that feeds into the health score.

CRASH (Critical)

Java and Kotlin exceptions — the FATAL EXCEPTION lines you’re already familiar with. Deep Inspector captures the full “Caused by” chain, which often reveals the real root cause buried three exceptions deep. A NullPointerException in your payment adapter might actually be caused by a JsonParseException from a malformed API response, wrapped in an IllegalStateException from your ViewModel. Deep Inspector captures all of it.

ANR (Critical)

Application Not Responding — the freeze that lasts 5+ seconds with no crash to investigate. When Android detects that your app hasn’t responded to an input event within the timeout window, it logs an “ANR in” entry. Deep Inspector detects these and captures the surrounding context, so you can see what your app was doing in the seconds before it froze. Input dispatch timeouts, broadcast receiver timeouts, service timeouts — all caught.

Native Crash (Critical)

SIGSEGV, SIGABRT, SIGBUS — the signals that kill your process at the native layer. If you’re using NDK libraries, camera APIs, or any third-party SDK with native code, these are the crashes that produce tombstones instead of stack traces. Deep Inspector detects the Fatal signal and tombstone patterns in logcat and captures whatever context is available.

OOM (High)

OutOfMemoryError — the crash that happens when your app tries to allocate more memory than the system can provide. Common triggers: loading large bitmaps without downsampling, leaking Activity contexts in long-lived objects, or accumulating data in an unbounded list. Deep Inspector flags these separately from regular crashes because the fix is almost always a memory management issue, not a logic bug.

GC Pressure (High)

When the garbage collector fires more than 5 times per second, something is wrong. Your app is allocating and discarding objects so fast that the GC can’t keep up. Deep Inspector tracks GC events in a sliding 1-second window and raises an alert when the threshold is exceeded. Common causes: creating objects inside onDraw(), string concatenation in tight loops, or allocating temporary objects per frame in animations.

Performance — Skipped Frames (Medium/Low)

Android’s Choreographer logs a warning whenever your app skips frames: Skipped 47 frames! The application may be doing too much work on its main thread. Deep Inspector captures these and classifies them by severity:

• 60+ frames skipped — Medium severity. Visible stutter, users notice.
• 30–59 frames skipped — Low severity. Marginal jank, worth investigating.
• Under 30 frames — Not reported. Normal variance.

WARNING (Low)

Any WARN-level log from your monitored apps. These are the early signals — the deprecation notices, the “resource not found” warnings, the “unexpected state” messages that developers log before the real problem manifests. Low priority, but valuable during active testing sessions when you want to catch everything.

Health Dashboard

When you open Deep Inspector’s Health tab, you see a dashboard — not a log viewer. The dashboard gives you an at-a-glance picture of how your monitored apps are doing.

Health Score (0–100)

A single number that summarizes the state of all your monitored apps over the last 24 hours. The formula:

Score = 100 - (critical issues × 30) - (high issues × 15) - (medium issues × 5) - (low issues × 1)

Clamped to 0–100. Three status labels:

A single crash drops your score by 30 points. Two crashes in 24 hours puts you in “Attention” territory. Three crashes plus an ANR puts you in “Critical.” The score resets naturally as issues age past the 24-hour window.

Quick Stats Row

Four numbers at the top of the dashboard:

• Crashes today — CRASH + NATIVE_CRASH count
• ANRs today — ANR count
• Warnings today — PERFORMANCE + GC_PRESSURE + OOM + WARNING count
• Monitored apps — Number of selected target apps

Per-App Health Cards

Below the quick stats, each monitored app gets a card showing its name, issue count summary, and individual health contribution. Apps with issues sort first (by health score, worst first), then healthy apps alphabetically. Tap any card to see the full issue list for that app.

Issue Timeline

A filterable list of the 20 most recent issues from the last 24 hours. Each entry shows a severity icon, title, message preview, timestamp, and occurrence count. Filter by: All, Crashes, ANRs, or Unresolved. Tap any issue to see full details.

Monitor Status Banner

A colored banner at the top of the dashboard shows the current state of the Health Monitor:

• Green — Running, actively monitoring
• Yellow — Paused
• Blue — Starting up
• Red — Error (with message)
• Gray — Stopped

The banner includes runtime duration and total issue count.

Context Capture: The Lead-Up, Not Just the Blow-Up

A stack trace tells you where the crash happened. The 50 log lines before the crash tell you why.

When the Health Monitor detects an issue, it doesn’t just capture the issue itself. It saves the rolling buffer of log context:

• 50 lines before the issue — the API call that returned a 500, the “retrying connection” message, the “unexpected null” warning that preceded the crash
• 20 lines after the issue — the system’s response, cleanup logs, follow-up effects

This context is stored per-issue and viewable in the issue detail screen, where you can filter by log level to cut through noise. If you only want the ERROR and WARN lines from the 70-line context window, one tap filters them.

This is arguably the most valuable part of the Health Monitor. A NullPointerException at PaymentAdapter.kt:47 is a location. The context log showing API response: {"error": "invalid_currency_code"} two seconds before the crash is the explanation.

Notifications: Know Instantly

When the Health Monitor detects an issue, you don’t need to have Deep Inspector open to know about it. The notification system alerts you in real time, with severity-appropriate urgency.

4 Channels by Severity

3 Actions Per Notification

Every issue notification includes three action buttons:

1. View Details — Opens the issue detail screen with full stack trace, context logs, and device state
2. Mark Resolved — Resolves the issue directly from the notification without opening the app
3. Analyze with AI — Reserved for a future update

Rate Limiting and Quiet Hours

A crashing app can generate hundreds of issues per hour. To prevent notification fatigue:

• Rate limit: 10 notifications per hour per app (configurable). Excess issues are still captured and visible in the dashboard — they just don’t trigger additional notifications.
• Quiet hours: Configurable window (default: 10 PM – 7 AM). No notifications during this window.
• Critical override: Crashes, ANRs, and native crashes can optionally bypass quiet hours. A crash at 3 AM is still a crash.

Each severity level can be independently enabled or disabled. If you only want to be notified about crashes and ANRs, disable Medium and Low.

Export: 4 Formats for Every Workflow

When you need to share logs or issues with your team, Deep Inspector offers four export formats through a guided export wizard.

Plain Text (.txt)

Formatted logcat output with aligned columns. Best for pasting into Slack, email, or bug reports where you want the raw log feel.

JSON (.json)

Structured data with metadata (export date, log count) and per-entry fields (timestamp, PID, TID, level, tag, message, package name). Best for feeding into analysis tools, scripts, or CI/CD pipelines.

CSV (.csv)

RFC 4180 compliant with proper escaping. Best for opening in spreadsheets, running pivot tables, or importing into databases.

HTML (.html)

A self-contained HTML5 document with a dark theme, color-coded log levels (each severity gets a distinct row color), monospace font, sticky headers, and click-to-expand message cells. Best for sharing human-readable reports that anyone can open in a browser without installing anything.

Export Scopes

You control what gets exported:

Export options let you toggle timestamps, PID/TID columns, and full vs. truncated messages. A progress bar shows export progress for large datasets.

Log Viewer vs Health Monitor

Deep Inspector has two modes that serve different purposes. Understanding the distinction helps you use each effectively.

Log Viewer

A real-time log browser. Start recording, and it captures all logcat output — from every app, every system service, every process on the device. You search, filter, bookmark, and browse. It’s the tool for active investigation: “What is happening on this device right now?”

The Log Viewer captures all log levels (Verbose through Assert) and stores up to 50,000 entries. You choose the logcat buffer (Main, System, Events, Crash, or All). It’s a general-purpose log tool.

Health Monitor

A background sentinel. Select which apps to monitor, start it, and put your phone down. When something goes wrong — a crash, an ANR, a memory issue, a performance drop — the Health Monitor detects it, captures context, and sends you a notification. It’s the tool for continuous monitoring: “Tell me if something breaks while I’m testing.”

The Health Monitor only captures ERROR, FATAL, and optionally WARN-level logs. It stores up to 1,000 logs per monitored app and runs the issue detection engine on every entry.

Using Both Together

The two modes run independently as separate foreground services. You can run both simultaneously:

• Health Monitor watches your app for crashes and performance issues in the background
• Log Viewer records a full verbose log of your testing session for later analysis

The Health Monitor catches the symptoms. The Log Viewer gives you the full diagnostic record.

Boot Recovery

If your device reboots while the Health Monitor is running, monitoring restarts automatically. Deep Inspector registers a boot receiver that:

1. Checks whether monitoring was active before the reboot
2. Waits 30 seconds for the system to stabilize (prevents false positives from boot-time system noise)
3. Restarts the Health Monitor with the same package selection and settings

You don’t need to reopen the app. Your monitoring survives reboots.

Target App Selection

You choose which apps the Health Monitor watches. The target app selection screen shows every installed app on the device with:

• Search — Find apps by name with 300ms debounce
• System apps toggle — Show or hide system apps (detected by vendor prefix: Google, Samsung, Qualcomm, Xiaomi, etc.)
• Select All / Clear All — Bulk selection
• TestNexus pinned first — Always visible at the top of the list

The Log Viewer captures everything regardless of this selection. Target app selection controls only the Health Monitor’s scope — which apps trigger issue detection and notifications.

Integration with Other Modules

Deep Inspector becomes more powerful when combined with other Test Nexus tools.

DataHub + Deep Inspector

Generate edge-case test data with DataHub — names with special characters, extreme numeric values, boundary-length strings — then monitor your app with Deep Inspector while you test. When the Brazilian name “Gonçalves” crashes your text encoder, Deep Inspector captures the full context: the crash, the 50 log lines before it, and the device state at the moment of failure.

ADB + Deep Inspector

Use the ADB module for verbose debugging sessions (logcat -d for one-shot dumps, shell commands for system state). Use the Health Monitor for structured, continuous detection. ADB gives you raw access; Deep Inspector gives you automated monitoring.

Terminal + Deep Inspector

SSH into your backend server from the Terminal module while Deep Inspector monitors the client app. When a client crash correlates with a server error, you can see both sides from the same device — the client crash in Deep Inspector, the server log in Terminal.

Get Started

If you’ve already set up the READ_LOGS permission from Post #04, you’re ready:

1. Open Test Nexus → Navigate to Deep Inspector
2. Tap the Health tab — You’ll see the Health Dashboard
3. Select target apps — Choose which apps to actively monitor
4. Start the Health Monitor — Tap the start button; monitoring begins in the background
5. Configure notifications — Adjust severity levels, quiet hours, and rate limits to match your workflow
6. Test normally — The Health Monitor runs in the background while you work
7. Check the Dashboard — Health score, issue timeline, and per-app status update in real time

If you haven’t set up READ_LOGS yet, see Post #04 for the one-time setup — one ADB command, and you’re done permanently.

Deep Inspector doesn’t just catch crashes — it monitors 7 issue types, scores your app’s health, and notifies you the moment something goes wrong. All on-device, all automatic, all without a USB cable. Download Test Nexus →

What’s Next

• Post #04 — Deep Inspector intro: crash capture without ADB, device context, and the one-time READ_LOGS setup
• Post #09 — Token System: what’s free and what uses tokens across every Test Nexus module