Crash reporting


Countly monitors the stability of your Android and iOS applications and helps increase user satisfaction with 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.

Please also see our FAQ for a list of questions and answers covering this plugin.

​​Countly's crash reporting dashboard allows you to classify crashes according to their resolution. You can mark a crash resolved and it’ll never appear again. Mark it 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, operating system and platform.​​

Below you can watch a video about crash reporting feature in Countly.

How can crash reports help you build a better app?

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

  • 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)
  • ...

iOS crash reporting

Crash reporting for iOS provides a means to capture crashes and exceptions. For more information, see iOS crash reporting page.

Android crash reporting

Crash reporting for Android provides a means to capture crashes and exceptions. For more information, read this documentation.

Countly Crash Analytics user interface allows you to easily overview 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 and how many users upgraded to resolved version of your application.

Main Page

The main page shows you 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 upgrade 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 specific app version but happened again in 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


Affected users will subtract only when user upgrade to the app version, that is higher than the version for which you resolved the crash

At the bottom of the same page, you can see 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 specific crash.


Countly can automatically group similar crashes so you don't have to.

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 checking which things you data want to share, so someone from the outside the system could also take a look at collected data for this 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 gives 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 screen in detail.

Also at the same page, there is a table with last 100 specific crash reports that were received from devices, where you can see data about specific crash occurrence, including any additional breadcrumb 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)

What are some of the terms that I see on dashboard?

Countly's crash dashboard is quite extensive - presents even more information than other crash analytics tools you have been using till now. For this reason, it's possible that you may get lost in a number of terminology. Below you can read the most important terms you can find in dashboard.

  • Crash: A crash is a software failure that causes the program flow to break unexpectedly. This term is usually used in iOS world.
  • Exception: An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions. This term is usually used in Java / 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 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 (marked as red in the bottom table).

Crash reports storage in server database

By default, all 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 id of your app, there is information about error groups. Here, 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 in dashboard.

Was this article helpful?
0 out of 0 found this helpful

Looking for help?