This User Guide is for the Crashes feature of Countly 20.11. To see the Crashes/Errors User Guide for the latest version of Countly, i.e., Countly 22.03, please click here.

Countly Crashes plugin monitors the stability of your Android and iOS applications and helps increase user satisfaction of your mobile apps. With the help of its real-time infrastructure, Countly shows which errors are trending in real-time, which users are impacted, and helps identify crashes by OS, device, carrier, and other factors, so that developers can remedy issues more quickly.

​​Countly's Crashes dashboard allows you to classify crashes according to their resolution. You can mark a crash as resolved and it’ll never appear again. Mark it as unresolved to take care of it later with your developers. Crash reports have lots of details to help you identify and resolve issues including, but not limited to, application version, platform, screen resolution, RAM, disk, battery level, and operating system.​​

Information Tracked and Collected

Crash reporting SDK is available for both Android and iOS, and it sends Countly servers the following information. Some of the data below may not be retrieved due to limitations on the platform.

Crash Related Information

• Operating system (e.g Android)
• Operating system version (e.g 5.1)
• Manufacturer (e.g Samsung)
• Device (e.g Galaxy S6)
• Resolution
• Application version
• CPU (e.g armv7)
• OpenGL version (e.g 2.0)

State of Device

• Free RAM size (e.g 2108, in MB)
• Total RAM size
• Free disk size (e.g 3400, in MB)
• Total disk size
• Current battery level (e.g 30)
• Orientation (landscape or portrait)

Boolean Data (yes/no)

• Is device rooted?
• Is device online?
• Is device muted?
• Was app in background?

Detailed Error Information

• Full stack of error
• Fatal or non-fatal
• Additional logs logged by SDK
• Running time since app start (seconds)

Custom key/values Provided by Developers

• Graphiclib (e.g 2.1)
• Paymentlib (e.g 1.0)

Metadata

Countly Crashes plugin provides device info as in Analytics by default, in addition to crash related data. You can add custom logs only to be delivered in case of a crash, independent of events. Moreover, you can set custom segments to specify which external libraries and frameworks are included in your project and their versions.

Exceptions

System signals (iOS) and uncaught exceptions (iOS and Android) are automatically handled by the Countly SDKs. You can also submit exceptions handled by yourself as well.

Out of Memory (OOM) Crashes

As terminations due to low memory cannot be considered as regular exceptions neither in iOS, nor in Android, it is not possible to handle them correctly. We're working on a solution for ANR in Android.

iOS Crash Reporting

Crash reporting for iOS provides a means to capture crashes and exceptions on any iOS device. For more information, see the crash reporting section in our iOS SDK document.

Using iOS SDK with Another Crash SDK

In iOS, there can be only one uncaught exception handler. Even though it is possible to save the previous handler and pass the uncaught exception to the previous handler as well, it is not safe to assume that it will work in all cases. As we can't know how other SDKs are implemented or whether iOS will give enough time for all the handlers to do their work before terminating the app, we advise to use Countly as the only crash handler.

Android Crash Reporting

Crash reporting for Android provides a means to capture crashes and exceptions on any Android device. For more information, read the crash reporting section in our Android SDK document.

The Countly Crashes user interface allows you to easily get an overview of all the crash information you have, identify the root cause of the crash by examining the segments and collected reports, and manage resolved and unresolved crashes including how many users upgraded to resolved version of your application.

Using Android SDK with Another Crash SDK

It should be fine to use Countly together with another crash SDK. If you would like to track caught exception, you would just pass them to both SDKs. When catching uncaught exceptions with both, there are some uncertainties. Although in Android there can be only one uncaught exception handler, you can save the previous handler and, when receiving an uncaught exception, pass it also to the saved one. We can't be certain how other SDKs are implemented or if the OS would give enough time to propagate the exception through all handlers. Therefore, if you want to use Countly with another crash SDK, we advise to initialize Countly as the last one.

Main Page

The main page shows you the overall time-series data about crashes and reports collected by SDKs.

Here you can see a timeline of:

• Crash occurrences (total occurrences and unique crashes)
• Crash types (fatal or non-fatal)
• Timeline of users having upgraded to the app version that had at least one crash fixed

Under timeline, you can see overall statistics, such as:

• How many unresolved crashes there are
• What is the latest app version released that had any crash
• How many new/unviewed crashes there are
• How many crashes reoccurred (were marked as fixed for a specific app version but happened again in a higher app version)
• How much potential revenue was lost by calculating average revenue per session at time of crash and multiplying sessions interrupted by crash

You can also see:

• Ratio of unresolved crashes
• Ratio of affected users by at least one fatal crash, non-fatal crash, and not affected users
• Top platforms
• Ratio between fatal and non-fatal crashes

At the bottom of the same page, you can see a list of crashes that have occurred. Crashes are labeled by tags for easy viewing.

You can also filter crashes by text or by their state as:

• All
• Resolved
• Unresolved
• New
• Viewed
• Reoccurred
• Fatal
• Non Fatal
• Hidden

You can click on them to view more detailed report about any specific crash.

Detailed Crash Information

On the crash detail page you can see more information about a specific crash.

On top, you can see the error stack and you can also mark this error as resolved for the latest version it occurred on. You can also comment on the crash and discuss it with other developers that have access to the same app. Comments also accept markdown format.

Here, you can also hide a crash or delete it. You can also share it publicly by first determining which points of the data you want to share, so that someone from outside of the system could also take a look at data collected for a crash. This is possible by generating a public link for this crash.

Below the page, you can segment a crash by collected values as:

• Application version
• OS version
• Manufacturer
• Device
• Resolution
• Orientation
• CPU model
• OpenGL
• Custom provided segments

This helps you easily identify if any specific parameter (like some specific version of used library) is the root cause of the crash.

And the last shown statistics provide the following information:

• Platform it occurred on
• Number of occurrences of the crash
• Number of affected users (both amount and percentage)
• Latest application version released having this crash
• Potential revenue losses for this specific crash

Moreover, the following information is also collected automatically:

• Ratio of devices that are rooted/jailbroken
• Ratio of devices that crashed while online
• Ratio of devices that crashed while muted (e.g. volume was 0)
• Ratio of devices that crashed while app was in background

Below, you can see that part of the platform in detail:

On the same page, there is a table with the last 100 specific crash reports that were received from devices, where you can see data about specific crash occurrence, including any additional breadcrumbs like crash logs you added through SDK.

It also shows the range values by showing minimal, maximal, and average values for ranges, such as:

• Amount of RAM used at the moment of crash
• Amount of disk space used at the moment of crash
• Amount of battery charged at the moment of crash
• How long the app was running before it crashed (in minutes/seconds)

Crashes Dashboard

Terms on the Dashboard

Countly's Crashes dashboard is quite extensive - it presents even more information than other crash analytics tools you may have been using until now. It's possible that, because of this reason, you may find yourself overwhelmed in a number of terminologies. Which is why we have assimilated the most important terms you can find in dashboard below:

• Crash: A crash is unexpected failure that causes the application process to break and stop functioning properly. This term is used for mobile and desktop applications. For web apps, the term “Error” is used, because web apps work on browsers where JavaScript failures cause errors on the app instead of breaking the browser.
• Exception: An exception is an event, which occurs during the execution of a program and that disrupts the normal flow of the program's instructions. This term is usually used in the Java and Android world.
• Total occurrences: Number of repetitions of a crash or group of crashes.
• Unique crashes: Number of crashes that happen uniquely. In this case, only first occurrence of a crash type is recorded.
• Non-fatal crashes: A crash that doesn't stop the application but allows it to run after a crash is encountered.
• Fatal crashes: A crash that causes the application to stop and quit.
• Unresolved crashes: Crashes that are not marked as "Resolved" are unresolved crashes.
• New crashes: New crashes that you haven't viewed as yet (marked as red in the bottom table).

Time for Crashes to Appear on the Dashboard

Countly SDKs send crash reports as soon as possible, before the app is completely terminated. If report cannot be sent at that time, it is stored to be sent on next app launch. This means that you can see crashes on your dashboard immediately, assuming the user has an active internet connection when the crash occurs.

This method is different from other crash reporting tools, as they send crash reports when the application is opened again. However in this method, if a user does not open your application again, the corresponding crash information that caused this behavior is never sent.

Crash Reports Storage in Server Database

By default, all crash reports are stored in Countly MongoDB collection app_crashes{APP_ID}, where APP_ID is ID of the corresponding application. The stack trace is stored in error property. All separate reports/occurrences are also stored in the same collection.

Inside app_crashgroups{APP_ID}, where APP_ID is the ID of your app, there is information about error groups. Same error reports are collected in one group. There, in error property, there is a stack trace of last error report or occurrence, and that is what you see on the dashboard.

Forcing Crashes

Countly SDKs currently do not have any method to force crashes, but it is really easy to do this in a few lines of code. For example, in iOS you can copy and paste this snippet:

NSArray* array = @[@"one",@"two",@"three"]; 
NSString* crashHere = array[5];

and one for on Android:

String array[] = {"one", "two", "three"};
String crashHere = array[5];

Status of Crashes

Status of Crash Marked as "Resolved" but Reappearing

When you mark a crash as resolved, you mark it resolved for a specific version. If the crash happened on same version or lower, it still stays resolved. If the crash happens on a version that is higher, the crash state is changed to "Reoccurred".

Status Marked as Hidden but Crash Reappears

If you mark the crash as hidden, then it stays hidden no matter what.

Duplication of Crash that Been Resolved in One Version but Appears in Another

This depends. If code was changed a lot between versions, then it might be a new crash, however if code remained mostly the same and has similar stack trace, then it would be the same crash.

FAQ and Troubleshooting

How do I use custom logging?

On iOS you need to use crashLog: method:

[Countly.sharedInstance crashLog:@"custom crash log"];

On Android there is Countly.addCrashLog():

Countly.sharedInstance().addCrashLog("This is custom log example number " + 1);

What is a fatal and non-fatal crash?

Fatal crashes are your app's unhandled crashes, which resulted in the user having to exit the app. These are collected automatically and reported to Countly server, if you enable this option in SDK.

Non-fatal crashes are crashes that you handled yourself in the app (like through try and catch blocks) but that you can still, optionally, report to Countly server for later examination.

Are crashes grouped?

Yes, we have a method that groups crashes so similar crashes are populated under the same group.