The Crashes/Errors feature lets you monitor application stability with real-time visibility into fatal and non-fatal issues across your Android, iOS, and web applications. The feature is called Crashes for mobile apps and Errors for web applications.

Benefits

The Crashes feature helps you quickly identify issues by OS, device, app version, and other factors. You can download detailed reports, track resolution status, and collaborate with your team through comments and JIRA integration. Real-time crash reporting ensures fast resolution, reducing user dissatisfaction and app uninstalls.

Getting Started

To start collecting crash data, enable crash reporting through the applicable Countly SDK. For platform-specific setup instructions, refer to the SDK guide below:

Crashes Overview

Supported Crash Types

Countly supports multiple crash types across platforms:

• Fatal crashes: Unhandled exceptions that are collected automatically when crash reporting is enabled.
• Non-fatal crashes: Handled exceptions (e.g., try/catch blocks) that you optionally report to Countly for tracking.
• Native C++ crashes: Native executable crashes with minidump support for symbolication.
• JavaScript errors: Web application exceptions captured via the Web SDK.

Information Collected

When crash reporting is enabled, the SDK sends the following data to the Countly server:

Crash Information

• Full stack trace
• Fatal or non-fatal classification
• Exception name and type
• Operating system and version
• Manufacturer and device model
• Screen resolution
• Application version
• CPU architecture
• OpenGL version
• Running time since app start (seconds)
• Additional logs from the SDK

Device State

• RAM usage (current and total, in MB)
• Disk usage (current and total, in MB)
• Battery level (percentage)
• Screen orientation (landscape or portrait)

Boolean Flags

• Is the device rooted/jailbroken?
• Is the device online?
• Is the device muted?
• Was the app running in the background?
• Did the device have cellular signal?

Build Information (Native Crashes)

• Architecture
• Build UUID
• Executable name
• Load address
• Binary images

Custom Data

Developers can attach custom key-value pairs to crash reports (e.g., library versions, feature flags, user context). You can also set custom segments to specify which external libraries and frameworks are included in your project and their versions. Additionally, you can add custom logs that are only delivered in case of a crash, independent of events. The server supports up to 100 unique custom field keys per crash group by default.

Crash Statuses

Crashes are categorized by their resolution status:

• New: Crashes that haven't been viewed yet.
• Viewed: Crashes that have been seen by a team member.
• Resolving: Crashes currently being worked on.
• Resolved: Crashes whose underlying issue has been fixed (resolved for a specific app version).
• Reoccurred: Crashes that were marked resolved but appeared again on a higher app version.
• Unresolved: Crashes not yet marked as resolved.
• Hidden: Crashes hidden from the main view to reduce clutter.

Crashes can also be filtered by fatality: Fatal, Non-fatal, or All.

Crash Resolution Behavior

• Resolved but reappearing: When you mark a crash as resolved, it is resolved for a specific version. If the crash reappears on the same or lower version, it stays resolved. If it reappears on a higher version, the status changes to "Reoccurred".
• Hidden crashes: Once hidden, a crash stays hidden regardless of new occurrences.
• Cross-version crashes: If a crash was resolved in one version but appears in another with significantly different code, it may be treated as a new crash group. If the code and stack trace are similar, it will be grouped with the existing crash.

Using Crashes

The Crashes feature consists of the following views:

• Crash Groups: Main Menu > Crashes > Overview (default view)
• Crash Statistics: Tab within the Overview page
• Crash Details: Click any crash group to view details
• Manage Symbols: Main Menu > Crashes > Manage Symbols

Crash Groups

The default view at Crashes > Overview displays crashes grouped by shared criteria.

Filtering Crash Groups

Filters are organized into two categories:

• Main filters: Fatality, visibility, resolution status, reoccurrence, new/viewed
• Detail filters: Device, app version, OS, platform, battery level, disk usage, RAM, CPU, OpenGL, orientation, and more

You can also use the advanced query builder for complex filtering across 20+ properties.

Crash Groups Data Table

The data table displays:

• Crash Group: Crash name, assigned developer, fatality and resolution tags
• Platform: OS on which the crash occurred
• Occurrences: Total number of times this crash occurred
• Last Occurrence: Time since the last occurrence
• Affected Users: Number of users impacted
• Latest App Version: Most recent app version where this crash appeared

Available table actions:

• Search: Filter crash groups using the search bar
• Download: Export the crash data as a report
• Customize Columns: Show/hide and reorder columns
• Bulk Actions: Select crash groups to mark as Seen, Resolved, Resolving, Unresolved, Hidden, or Delete

Crash Statistics

Click the Crash Statistics tab on the Overview page to see aggregate statistics and trend graphs for a selected time period.

Statistics Widgets

• Affected Users: Percentage and count of users impacted by crashes. The affected users count will only decrease when users upgrade to an app version higher than the version for which you resolved the crash.
• Resolution Status: Percentage of crashes resolved
• Crash Fatality: Percentage of fatal vs. non-fatal crashes
• Top Platforms: Platforms with the most crashes
• New Crashes: Count of unviewed crashes
• Reoccurred Crashes: Count of crashes that have come back after resolution
• Revenue Loss: Estimated revenue lost due to sessions with crashes
• Latest App Version: Current version of your app

Statistics Graph

The graph shows metrics for both the selected period and the previous period (the same number of days immediately preceding the selected period). To populate data in the graph, first set up a time period using the dropdown above the graph, then set the crash filters using the dropdown next to the time period. This will populate both the widgets and the graph with the following metrics:

• Total Occurrences: Total crash count for the applied filter
• Unique Crashes: Number of distinct crash groups (first occurrence only)
• Crashes/Session: Crash rate per session (percentage)
• Crash-free Users: Percentage of users who did not experience a crash
• Crash-free Sessions: Percentage of sessions without a crash

You can view any widget's data on the graph for the selected and previous periods by clicking on the relevant widget.

Crash Details

Click any crash group to view its details. The applied segmentation is shown at the top of the page next to Segmentation Applied. To change the segmentation, click Back at the top left to return to the Crash Groups page.

Summary Widgets

• Platform: OS where the crash occurred
• Occurrences: Total occurrence count
• Affected Users: Number of impacted users
• Crash Frequency: Occurrences relative to total sessions
• Latest App Version: Most recent version with this crash

Stack Trace

The full stack trace is displayed below the summary. You can toggle between Crashed Thread and All Threads for native crashes. Stack traces can be downloaded as .txt files, and binary crash dumps can be downloaded as .dmp files for native crashes.

Comments

Team members can add, edit, and delete comments on crash groups to coordinate resolution efforts. Click the Comments tab to view and manage comments. Each comment shows the author, timestamp, and edit history.

Crash Metrics

Detailed device metrics at the time of the crash (shown as average, minimum, and maximum):

• RAM: Memory usage when the crash occurred
• Disk: Disk usage when the crash occurred
• Battery: Battery level when the crash occurred
• Running: App uptime before the crash
• Sessions: Average sessions before the crash
• Rooted/Jailbroken: Percentage of affected devices that were rooted
• Crashed When Online: Percentage of devices that were online
• Crashed While Muted: Percentage of devices that were muted
• Crashed in Background: Percentage of devices where the crash occurred in the background

Occurrences Graph

The occurrences graph shows crash frequency over time. You can filter by platform, app version, city, and other dimensions.

Crash Occurrences Table

Individual crash occurrences listed by user, with the following columns:

• Crashed: When the user last experienced this crash
• OS Version: The device OS version
• Device: Device model
• App Version: App version at the time of crash
• User: User name or ID

Click any row to expand the full occurrence details:

• Build Info: Architecture, build UUID, executable name
• Device: Full device specifications
• Device State: RAM, disk, battery, and boolean flags at crash time
• Custom Data: Developer-provided key-value pairs
• Stack Trace: Full error trace for this specific occurrence
• Event Logs: Events before and after the crash (configurable in Settings > Crashes)
• SDK Logs: Raw data from the SDK

You can download occurrence reports, search for specific users, and navigate to full user profiles from this table.

Crash Symbolication

The Crash Symbolication plugin converts obfuscated or minified stack traces into human-readable format. Navigate to Main Menu > Crashes > Manage Symbols to manage symbol files.

Supported Formats

• iOS: Upload .dSYM files as .zip archives
• Android: Upload ProGuard/R8 mapping files as .txt
• Android Native (C++): Upload symbol files as .tar.gz archives
• JavaScript: Source map deobfuscation for web applications

Managing Symbol Files

In the Manage Symbols view, you can:

• Upload new debug symbol or mapping files
• Associate symbols with specific build versions and platforms
• Edit, download, or delete existing symbol files
• Add notes to symbol files for reference

Automatic Symbolication

When enabled, Countly automatically symbolicates incoming crash reports using uploaded symbol files. The symbolication process runs as a background job, and you can check progress in Symbolication Logs. You can also manually trigger resymbolication from the crash detail view.

Symbolication Server

Symbolication can be performed by an external symbolication server. Configuration options include:

• Symbolication Server URL: The address of the symbolication server
• Symbolication Server API Key: Authentication key for the server
• Custom external domain: Optional custom domain for the return connection

Use the Test Connection button in settings to verify the server connection and API key validity.

JIRA Integration

Countly Enterprise includes JIRA Integration for crash analytics. This allows you to:

• Create JIRA issues directly from crash groups in Countly
• Link crash details (including stack traces) to JIRA tickets
• Map crash resolution states to JIRA workflow states (To Do, Doing, Done)
• Open linked JIRA issues from within Countly

JIRA integration uses OAuth 1.0 authentication. Configuration requires a consumer key, JIRA API URL, private key, and callback URL. See the JIRA Integration setup guide below for details.

Configuration

Crash settings can be configured in Settings > Crashes:

• Crash grouping strategy: Choose how crashes are grouped:
  • Error and file (default): Groups by error name and the file where the error occurred
  • Full stack trace: Groups by the complete stack trace
• Smart stack trace preprocessing: When enabled, automatically cleans stack traces by removing dynamic values (memory addresses, object IDs, file paths, IP addresses) to improve grouping accuracy.
• Smart regexes: Custom regex patterns for removing additional dynamic information from stack traces during grouping.
• Latest crash update: Controls whether crash details are updated only when a crash occurs on a newer app version.
• Report limit: Maximum number of crash reports displayed per request (default: 100).
• Maximum custom field keys: Limit on unique custom data keys per crash group (default: 100).
• Custom field cleanup job: When activated, a daily job removes excess custom field values to keep the data within the configured limit.

Data Storage

Crash data is stored in MongoDB with per-app collections:

• app_crashes{APP_ID}: Individual crash reports with full stack traces, device state, and custom data.
• app_crashgroups{APP_ID}: Aggregated crash groups with occurrence counts, affected users, resolution status, and segment breakdowns. The stack trace shown in the UI is from the latest occurrence.
• app_crashusers{APP_ID}: Per-user crash impact tracking (crash count, sessions, last occurrence).

Real-Time Crash Reporting

Unlike other crash reporting tools that wait until the next app launch, Countly SDKs send crash data immediately when a crash occurs. If the report cannot be delivered (e.g., no internet connection), it is stored locally and sent on the next app launch. This means crashes appear in Countly in real time when users have an active internet connection.

The advantage of this approach is that tools which only send crash reports on the next app launch risk losing crash data entirely if a user never reopens the application after the crash.

FAQ

How are crashes grouped?

Countly groups crashes automatically based on the configured grouping strategy. By default, crashes are grouped by the error name and the file where the error occurred. You can change this to group by the full stack trace in Settings > Crashes. Smart preprocessing removes dynamic values (memory addresses, IDs, file paths) to improve grouping accuracy.

How does crash resolution work across app versions?

When you resolve a crash, it is marked resolved for the current app version. If the same crash reappears on the same or lower version, it remains resolved. If it appears on a higher version, the status changes to "Reoccurred" so your team can investigate whether the fix regressed.

Can I hide crashes without deleting them?

Yes. Use the Hide action to remove a crash from the main view. Hidden crashes stay hidden regardless of new occurrences and can be shown again at any time.