Fatal Issues & Crashes: Feature Guide¶
Beta
This feature is currently experimental and opt-in. Get in touch with us if you'd like to try it.
bitdrift’s fatal issue tracking helps mobile teams detect, prioritize, and resolve crashes with full session-level context. This guide walks through the key pages and features available in the issues portal.
Core Concepts¶
- Issue: An issue represents any event that causes the app to close abruptly and disrupts the normal flow of a program. bitdrift groups recurring crash events into a single issue based on signature so that you can focus on impact instead of duplicates.
- Occurrence Trend: A timeline chart that visualizes how often an issue occurs over time. This helps track regressions, verify fixes, and detect spikes in severity.
- Trend Filters: Apply filters based on metadata like device type, OS version, app version, network status. Use these to isolate issues affecting specific segments of your mobile fleet.
- View: A View is a customized, filter-based list of issues saved by a user. Views let teams tailor and share the issue list to match their workflow—whether that’s triaging new crashes or monitoring stability in a specific release.
Info
See the SDK > Fatal Issues section for information about how to configure this feature in your apps.
Issues¶
The Issues page is your starting point for identifying and triaging the most impactful crashes across your mobile apps. It provides both a high-level view of crash trends over time and a detailed list of grouped issues with powerful filtering options.
Occurrence Trend¶
You'll find a timeline visual at the top of the Issues page that charts the total number of fatal issue occurrences over time. This makes it easy to spot spikes, regressions, or changes in crash volume across your fleet.
Grouped Issues List¶
Beneath the timeline is a grouped list of all detected fatal issues. Each group includes:
- Issue name or crash signature
- App and platform
- An occurrence trend mini-chart
- When the issue was last seen
- The time since the issue was seen for the very first time, regardless of date and time range filtering
- A count of events when the issue was seen
- The number of impacted user devices
- The number of impacted sessions
This view helps you quickly identify which issues are happening most frequently and have the broadest impact.
Filters¶
Filters help you narrow the list of issues so you can focus on what matters—crashes in a specific release, on a certain platform, or affecting particular user environments. You can combine multiple filters to build precise queries. Filters can be saved globally across your organization via saved views which in turn can be shared using permalinks.
bitdrift supports several powerful filtering options:
- Platform & Application: Use the multiselect dropdown to quickly choose one or more platforms (e.g., iOS, Android) and applications in your org. This is useful when monitoring multiple apps or platforms in the same workspace.
- Date & Time Range: Use the date picker to define the time window for issue data. You can choose relative ranges (e.g., last 7 days) or custom start and end dates. This is useful for tracking regressions, verifying fixes, or reviewing crash activity during a specific release period.
- Trend Filters: Drill down using session-level metadata associated with each crash. Trend filters include:
- App version
- App foreground/background status
- User locale
- Device model
- Network type (Wi-Fi, cellular, etc.)
- OS version
- Radio type (e.g., LTE, 5G, etc.)
These filters help isolate issues affecting only specific devices, user segments, or runtime conditions.
Saved Views¶
If you regularly triage crashes by specific criteria—like release version or device type—you can create a custom view to help streamline your workflow.
To create a reusable filtered view, click the "+" button at the top of the page, give your view a name, and save by selecting the green check mark or hitting the Return key. Select your desired filters and save the View using the dropdown to the right of the title. You can adjust filters later and save changes to update the view. The browser URLs on Views are permalinks that you can safely copy and share.
Tip
Use the Search Omnibar (⌘ / ctrl + k) to quickly search for a specific Saved View using their names.
Issue Reports¶
Clicking on any issue from the Issues list brings you to the Individual Issue Reports—a high-level dashboard showing how widespread the issue is and where it’s occurring.
At the top of this view you can find the Issue Title, and Reason. The issue reports are also implicitly grouped by a specific platform and app.
Filters¶
At the top of the view, you can also narrow your results using
- Date/Time Range: Focus the analysis on a specific window (e.g. last 24 hours, current release cycle)
- Trend Filters: Filter by app version, device model, OS version, locale, network type, and other contextual metadata
Key Metrics¶
Three summary cards highlight the overall impact of the issue:
- Affected Users: Number of distinct impacted user devices in the time range, and the total number of user devices affected by this issue overall.
- Events: Number of events recorded during the time range, and the total number of issue reports.
- Affected Sessions: Number of distinct impacted sessions in the time range, and the total number of sessions affected by this issue overall.
Occurrence Timeline¶
A visual timeline shows how frequently the issue has occurred over time. This helps identify spikes, regressions, or declines following a release or fix.
Issue Reports List¶
Below the metrics and timeline, a table displays a list of sampled crash events. Each row includes:
- Issue details
- App version
- Timestamp of the event
Clicking any row takes you directly to the Stack Trace View for that specific occurrence.
Issue Report Details¶
The Issue Report View provides a detailed look into the crash that occurred during a user session. It’s designed to help developers quickly pinpoint the exact line of code and thread where the crash originated.
Crash Summary & Metadata¶
At the top of the view, you’ll see a summary of the issue, including:
- The issue details - usually the top frame of a stack trace
- Platform and app
- Device model
- Whether the app was in the foreground or background
- Network type (e.g., Wi-Fi, Cellular)
- Radio type (e.g,. LTE, 5G)
- User device locale
This metadata provides helpful context for reproducing and debugging the crash under real-world conditions.
Thread Navigation¶
Crashes often occur on one thread, but it’s helpful to inspect others that were running concurrently. bitdrift provides two ways to explore:
- Thread Dropdown: An auto-complete dropdown menu lets you find and select any thread that was active at the time of the crash
- Arrow Navigation: Use the
<and>buttons to quickly cycle through available threads
The thread that triggered the crash is clearly labeled as Captured Error. All other threads are numbered for easy reference.
Tip
You can search for keywords across all threads using your regular browser search.
Stack Traces¶
Info
In order to generate human readable stack traces, bitdrift needs your apps' debug information files. Visit the SDK > Debug Information section for instructions on how to upload such data.
All stack traces show:
- File names
- Class and method names
- Line numbers
- Module or binary names (for native code)
This makes it easier to trace the crash back to your source code—whether it originated in Java, Kotlin, Swift, Objective-C, or native C/C++.
Session Timeline and Replay¶
Stack traces are now displayed side by side with the session timeline, replay, and span views—so you can see exactly what led to a crash, not just where it occurred.
Refer to each tabs' section for more information: