Fatal Issues & Crashes: Feature Guide¶
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.
Info
See the SDK > Fatal Issues section for information about how to configure this feature in your apps.
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.
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.)
- Report Type (e.g. JVM, Native, ANR etc.)
- Feature flags
These filters help isolate issues affecting only specific devices, user segments, or runtime conditions.
Tip
Many filters support multiple selections or wildcards. For example, you can select multiple device models or use iPhone* to match all iPhone variants.
Info
Semver fields such as App Version and OS Version support advanced operators like >, <, >=, and <= to help you filter by version ranges. For example, to see crashes affecting iOS 16 and above, you could use the filter OS Version >= 16.0. They also support multiple instances of the same filter, e.g. App Version >= 1.0.0 and App Version < 2.0.0 to see crashes affecting all versions in the 1.x series. Semver matching does not fully implement all aspects of semantic versioning. Major, minor, and patch versions are supported, as well as a basic support for pre-release tags.
- Raw Search: Within the Filter bar, you can also enter freeform text to search across a number of issue fields. This is useful for quickly locating a specific issue by reason or context.
Saved Views¶
If you regularly triage crashes by specific criteria—like release version or monitoring regressions via Alerts—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.
Alerts & Notifications¶
bitdrift provides two ways to stay informed about crashes without relying solely on dashboards:
- Alerts monitor for crash patterns over time and fire when conditions are met.
- Notifications trigger instantly when a new or critical issue occurs.
Tip
Use Alerts to monitor crash trends over time, and Notifications to capture new or rare issues the moment they occur.
Both Alerts and Notifications are associated to a specific Saved View.
A View already defines a set of filters (e.g., by platform, app version, device type), and you can attach alert configurations to that View to monitor the same scope automatically.
- Each View can have as many alert configurations as you need.
- Each View can have at most one of each notification type.
Alerts¶
Alerts are designed for tracking ongoing patterns:
- Frequent Errors: Fires when crashes exceed a defined threshold within a set time window.
- Trending Errors: Fires when crash increase compared to their same value in a previous period.
Alerts can be configured with:
- Metrics. Impacted users, sessions, or events.
- Thresholds & Durations. e.g., 50 crashes in 10 minutes.
- Scopes & Filters. app version, platform, device type, locale, etc. (defined via the filters in the Saved View)
Percent-Based Alerts¶
Some alert conditions let you trigger on percentages of affected sessions or affected user devices rather than absolute counts.
How Percentages Are Calculated¶
The percentage is calculated using the gross total of sessions or user devices observed in the selected time window for the given app_id.
- This does not take into account additional filters applied in the View.
- Percentages therefore reflect app-wide impact, but may differ from filtered counts shown elsewhere in the portal.
Example¶
If a view is filtered to only show sessions from iOS 18 devices, but the app_id has 10,000 sessions overall in the last 24 hours, then:
- The denominator for the percentage is 10,000 (all sessions), not just the iOS 18 subset.
- If 500 sessions were affected, the alert condition would evaluate as 5%.
Notifications¶
Notifications provide immediate visibility into critical events:
- New Errors: Fire when a previously unseen crash signature is detected.
- Every Error: Fire for each occurrence of a crash, useful when investigating rare but severe issues.
Notifications Delivery¶
Both alerts and notifications can be routed to Slack and other channels. Each firing includes direct links to the related Issue Reports and Stack Traces, ensuring fast investigation.
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.
Feature Flags¶
The "Feature Flags" tab will show a list of all flags that were active when the issue occurred, as well as any variants set.
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 human-readable 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++.
In-App Frames (Android)¶
In order to detect which frames in a stack trace belong to your app, bitdrift automatically looks for fully qualified function names that start with your applicationId/packageName. If you want to further customize this logic you can do so via the Company Settings menu.
To add a package prefix:
- Navigate to Company Settings > Issue Grouping.
- Click Add Package Prefix and enter your application’s package name or company's reversed domain (e.g.
com.company). You can add as many entries as you want. - Once registered, all in-app frames that match that prefix will be attributed to your app.
Existing Issue Groups
Uploaded package names will only be applied to new issue events. Existing events will not be grouped/attributed retroactively.
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: