Firebase Crashlytics — What It Is, Crashes and Crash Diagnostics

What is Firebase Crashlytics

Firebase Crashlytics is a free Google service for monitoring mobile app stability, acquired by Google in 2017 along with the Fabric company. Crashlytics automatically collects information about every app crash, groups identical crashes by stack signature, and displays them in the Firebase console prioritized by the number of affected users.

History and Evolution

Crashlytics was launched in 2011 as part of the Fabric platform and quickly became the de facto standard for crash reporting in iOS. After its acquisition by Google in 2017 for an estimated $2 billion (the entire Fabric), Crashlytics was integrated into the Firebase SDK. Version 18.0.0 (2021) added Kotlin Multiplatform support, and version 19.0.0 (2024) introduced automatic ANR collection on Android without additional setup. According to Google (2026), Crashlytics processes over 10 billion crashes monthly.

Free Limits of Crashlytics

Crashlytics is provided for free with a limit of 500 thousand sessions per day per Firebase project. This is sufficient for most apps — according to Google (2026), 95% of projects do not exceed the limit. When exceeded, data collection does not stop, but reports stop updating until the next day. For high-traffic projects, Spark and Blaze Firebase pricing tiers are available — Crashlytics remains free on both tiers, and the session limit is counted separately.

How Crashlytics Detects and Collects Crashes

The collection mechanism of Crashlytics is based on intercepting exceptions at the platform and runtime level. On Android, the SDK installs an UncaughtExceptionHandler that catches all unhandled Kotlin and Java exceptions. On iOS, Crashlytics uses NSSetUncaughtExceptionHandler for Objective-C/Swift and its own Mach exception handler for native code crashes.

Types of Intercepted Crashes

Crashlytics distinguishes five types of crashes: fatal (fatal crashes), non-fatal (non-fatal exceptions passed manually), ANR (Android — Application Not Responding), signal (OS signals — SIGSEGV, SIGABRT) and OOM (out of memory on iOS). Each type is handled by a separate mechanism and displayed in the console with the corresponding label.

Crash Report Format

Each Crashlytics report contains comprehensive information: a full stack trace with class names and line numbers, app version (versionName + versionCode), device model, OS version, available memory, screen orientation, and time since launch. If Firebase Analytics is connected, the report also includes the path of the last 50 user events before the crash — this is critical for crash reproduction.

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Integrating Crashlytics into an Android Project

Connecting Crashlytics to an Android app requires adding two dependencies in build.gradle and configuring the Google Services plugin. The SDK automatically enables crash reporting upon Firebase initialization without additional code. For proper operation, the google-services plugin and the google-services.json file from the Firebase console are also required.

// build.gradle (project-level)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (app-level)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Configuring the Crashlytics Plugin

The com.google.firebase.crashlytics plugin performs two tasks: generates a unique build ID for mapping obfuscated stacks and automatically creates resources for the Crashlytics SDK. Without the plugin, crashes will be marked as "unmapped" — you will only see obfuscated class names (a.b.c) without being able to find the source code. The plugin is added to the root build.gradle and the app module's build.gradle.

Verifying Integration

To test the Crashlytics integration, the special method forceCrash() is used, which generates a test exception. This method is unavailable in production builds. After running a test crash, the report appears in the Firebase console within 1-5 minutes. If the report does not appear, check that google-services.json matches the app package and that there are no flags in AndroidManifest disabling data collection.

Crash Analysis and Report Grouping

The Crashlytics Console provides two levels of viewing: a list of all crashes (Issues) grouped by crash type, and a detailed report for each Issue with trace, statistics, and custom data. Each Issue combines all crashes with the same signature — the same exception type and matching stack trace.

Issues and Grouping

Crash grouping is a key feature of Crashlytics. Instead of showing thousands of individual crashes, the service combines them into Issues based on a fingerprint — a checksum of the stack trace. One Issue can contain from 1 to several million crashes. Each Issue displays: the number of fatal occurrences, the number of unique users, the app version in which the crash appeared, and the percentage of users who encountered the problem.

According to Google (2026), on average 20% of Issues account for 80% of all fatal app crashes (Pareto principle). Crashlytics automatically sorts Issues by severity — the more users affected, the higher the priority. This allows the developer to fix the most widespread problems first.

Version Statistics

Crashlytics tracks the stability of each app version separately. The crash-free users chart shows the percentage of users who did not encounter a fatal crash in each version. If the percentage drops below a threshold (default 99%) upon update, Crashlytics sends a notification by email and in the Firebase Console. This allows quickly rolling back a problematic version or releasing a hotfix.

Custom Keys, Logs and Breadcrumbs

Crashlytics provides three mechanisms for enriching reports with context: custom keys for structured data, logs for text tracing, and Breadcrumbs from Analytics for the user path. All three data types are attached to the crash report and visible in its detail card.

Custom Keys

Custom Keys are key-value pairs that are sent with each crash. Maximum 64 keys per app, each key is a string up to 1024 characters. Keys are useful for labeling app state: subscription level, authorization status, last screen, whether VPN is enabled. Values are overwritten — a new key with the same name replaces the old one.

Event Logging

Custom Logs are text messages that Crashlytics stores in a 64 KB ring buffer. Logs are automatically attached to the next crash. If no crash occurs, logs are not sent to the server (they do not consume traffic). Logging is used to record user steps before the crash: "payment_processing_started", "api_call_initiated", "response_received_200".

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Breadcrumbs from Analytics

If Firebase Analytics is connected to the project, Crashlytics automatically receives Breadcrumbs — the last 50 analytics events before the crash. Each breadcrumb contains the event name and its parameters. This allows reconstructing the exact sequence of actions that led to the crash: user opened screen → added item → proceeded to payment → crash occurred. Breadcrumbs are displayed in the Issue card on a separate "Logs" tab.

Best Practices for Working with Crashes

Crashlytics is most effective when the context and issue handling process are properly configured. Practice shows that teams that have implemented a crash management workflow reduce critical bug fixing time by 60% (Google data, 2026).

Issue Prioritization

Not all crashes are equally important. Prioritization by user count and frequency helps focus on the most critical problems. Rule of thumb: fix Issues affecting more than 0.1% of users within 24 hours. Issues with single occurrences (< 0.01%) can be deferred until the next planned release. Crashlytics automatically marks regressions — Issues that were fixed but reappeared in a new version.

CI/CD Integration

The Crashlytics API allows integrating crash reports into the CI/CD pipeline via REST API or Firebase CLI. With each new release, you can automatically check whether the crash-free users percentage exceeds a threshold. If the threshold is exceeded, CI/CD blocks the rollout and sends a notification to the team. The Firebase CLI supports the firebase crashlytics:builds:upload command for uploading ProGuard/R8 mapping files — without them, stacks will be unreadable.

According to Google (2026), apps that use automatic crash-free threshold checking in CI/CD release 40% fewer regressions to production. Recommended threshold: crash-free users >= 99.5% for critical releases and >= 99.0% for regular ones.