Each crash report reaches your dashboard with all the information you need to resolve it.
The crashes page in your dashboard lists all of your crash reports. When you select one, it opens the crash overview page where you can find more details about that crash.
The graph above depicts the number of crashing sessions caused by this particular crash against the days of the previous month. Each line color represents a different app version.
Here are what the details in the crash page cover:
- Exception & Crash Cause: The main application frame that caused the crash.
- Occurrences: The number of times this crash occurred.
- Affected Users: The number of unique users that experienced this crash.
- Occurrences over time: Shows the number of occurrences over time for each app version.
- Max App Version: The highest version of the app this crash occurred on.
- App Versions: A breakdown of the crash occurrences by app version.
- Devices: A breakdown of the crash occurrences by device model.
- OS version: A breakdown of the crash occurrences by OS version.
- App status: A breakdown of the crash occurrences by background or foreground state.
- Current view: A breakdown of the crash occurrences by the app view they occurred on.
- Experiments: A breakdown of the crash occurrences by different feature flags (if any are specified).
- User attributes: A breakdown of the crash occurrences by custom user attributes (if any are specified).
In each crash report, you can find the stack trace of the crash with the most important frames highlighted in blue. These highlighted frames are your application's frames. In order for these crashes to be readable, symbolication is required. More information on symbolication can be found here. A stack trace is captured and shown per app version within the crash itself.
Sometimes, different stack traces are related to different teams within your organization. In an effort to allow for a more efficient method of assigning crash reports to the related teams, you can set up code ownership rules that use paths and filenames as conditions to allow for a more automated workflow.
In the rules page, you can use code ownership to check for specific paths and filenames, these are then compared against the first non-system frame in the stack trace.
When setting up the rule, Instabug supports partial matching of paths using the match condition (not case sensitive), let's take a look at some examples:
Actual Crash Path: instabug/crashes/list/singleCrash
|Successful Match||Unsuccessful Match|
- instabug//crashes - contains an extra slash in the middle
- /instabug/crashes - contains an extra slash before instabug
- com/instabug/crashes/list/singleCrash/ - contains an extra slash after singleCrash
- instabug/crashes/list/singleCrash/Occurrence - contains an extra sub-path
- instabug/cr/list - Instabug does not match partial words (cr and crashes in this case)
- crashes/instabug - path is written in a wrong order
Each crash has occurrences, a unique instance of that crash. With each occurrence, you can find extra details about every instance, such as logs, Session Profiler, and User Attributes. You can go through these unique occurrences by clicking on the Occurrences button.
You can add tags to crash reports for filtering and analysis. More details regarding these tags can be found here.
Updated 3 months ago
Since you're now familiar with the content of a crash report, familiarize yourself with the content of each occurrence as well.