This page provides troubleshooting help and answers to frequently-asked questions about using Crashlytics. If you can't find what you're looking for or need additional help, contact Firebase support.
General troubleshooting/FAQ
If you're not seeing crash-free users, breadcrumb logs, and/or velocity alerts, we recommend checking your app's configuration for Google Analytics.
Make sure that you've enabled Google Analytics in your Firebase project.
Make sure that Data sharing is enabled for Google Analytics in the Integrations > Google Analytics page of the Firebase console. Note that Data sharing settings are displayed in the Firebase console but managed in the Google Analytics console.
In addition to the Firebase Crashlytics SDK, make sure that you've added the Firebase SDK for Google Analytics to your app (iOS+ | Android).
Make sure that you're using the latest versions for all your Firebase SDKs (iOS+ | Android).
Especially check that you're using at minimum the following versions of the Firebase SDK for Google Analytics:iOS+ — v6.3.1+ (v8.9.0+ for macOS and tvOS) |Android — v17.2.3+ (BoM v24.7.1+) .
The crash-free value represents the percentage of users who engaged with your app but did not have a crash over a specific time period.
Here is the formula for calculating the crash-free users percentage. Its input values are provided by Google Analytics.
1 - (CRASHED_USERS / ALL_USERS)
When a crash happens, Google Analytics sends an
app_exceptionevent type, and CRASHED_USERS represents the number of users associated with that event type.ALL_USERS represents the total number of users who engaged with your app over the time period that you've selected from the dropdown menu in the upper-right of the Crashlytics dashboard.
You can view the number of app_exception events for your app in the
Analytics dashboard. Note that due to minor differences in how crashes are
processed, the app_exception number displayed in the Analytics dashboard
may sometimes differ from the number used in the crash-free users calculation.
The crash-free users percentage is an aggregation over time, not an average.
For example, imagine your app has three users; we'll call them User A, User B, and User C. The following table shows which users engaged with your app each day and which of those users had a crash that day:
| Monday | Tuesday | Wednesday | |
|---|---|---|---|
| Users who engaged with your app | A, B, C | A, B, C | A, B |
| User that had a crash | C | B | A |
On Wednesday, your crash-free users percentage is 50% (1 out of 2 users was crash-free).
Two of your users engaged with your app on Wednesday, but only one of them (User B) had no crashes.For the past 2 days, your crash-free users percentage is 33.3% (1 out of 3 users was crash-free).
Three of your users engaged with your app over the past two days, but only one of them (User C) had no crashes.For the past 3 days, your crash-free users percentage is 0% (0 out of 3 users were crash-free).
Three of your users engaged with your app over the past three days, but zero of them had no crashes.
Integrations
If your project uses Crashlytics alongside the Google Mobile Ads SDK,
it's likely that the crash reporters are interfering when
registering exception handlers. To fix the issue, turn off crash reporting in
the Mobile Ads SDK by calling disableSDKCrashReporting.
After you link Crashlytics to BigQuery, new datasets you create are automatically located in the United States, regardless of the location of your Firebase project.
Platform support
Regressed issues
An issue has had a regression when you've previously closed the issue but Crashlytics gets a new report that the issue has re-occurred. Crashlytics automatically re-opens these regressed issues so that you can address them as appropriate for your app.
Here's an example scenario that explains how Crashlytics categorizes an issue as a regression:
- For the first time ever, Crashlytics gets a crash report about Crash "A". Crashlytics opens a corresponding issue for that crash (Issue "A").
- You fix this bug quickly, close Issue "A", and then release a new version of your app.
- Crashlytics gets another report about Issue "A" after you've closed the
issue.
- If the report is from an app version that Crashlytics knew about when you closed the issue (meaning that the version had sent a crash report for any crash at all), then Crashlytics won't consider the issue as regressed. The issue will remain closed.
- If the report is from an app version that Crashlytics did not know about when you closed the issue (meaning that the version had never sent any crash report for any crash at all), then Crashlytics considers the issue regressed and will re-open the issue.
When an issue regresses, we send a regression detection alert and add a regression signal to the issue to let you know that Crashlytics has re-opened the issue. If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.
If a report is from an old app version that had never sent any crash reports at all when you closed the issue, then Crashlytics considers the issue regressed and will re-open the issue.
This situation can happen in the following situation: You've fixed a bug and released a new version of your app, but you still have users on older versions without the bug fix. If, by chance, one of those older versions had never sent any crash reports at all when you closed the issue, and those users start encountering the bug, then those crash reports would trigger a regressed issue.
If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.