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
You might notice two different formats for issues listed in your Issues table in the Firebase console. And you might also notice a feature called "variants" within some of your issues. Here's why!
In early 2023, we rolled out an improved analysis engine for grouping events as well as an updated design and some advanced features for new issues (like variants!). Check out our recent blog post for all the details, but you can read below for the highlights.
Crashlytics analyzes all the events from your app (like crashes, non-fatals, and ANRs) and creates groups of events called issues — all events in an issue have a common point of failure.
To group events into these issues, the improved analysis engine now looks at many aspects of the event, including the frames in the stack trace, the exception message, the error code, and other platform or error type characteristics.
However, within this group of events, the stack traces leading to the failure might be different. A different stack trace could mean a different root cause. To represent this possible difference within an issue, we now create variants within issues - each variant is a sub-group of events in an issue that have the same failure point and a similar stack trace. With variants, you can debug the most common stack traces within an issue and determine if different root causes are leading to the failure.
Here's what you'll experience with these improvements:
Revamped metadata displayed within the issue row
It's now easier to understand and triage issues in your app.Fewer duplicate issues
A line number change doesn't result in a new issue.Easier debugging of complex issues with various root causes
Use variants to debug the most common stack traces within an issue.More meaningful alerts and signals
A new issue actually represents a new bug.More powerful search
Each issue contains more searchable metadata, like exception type and package name.
Here's how these improvements are rolling out:
When we get new events from your app, we'll check if they match to an existing issue.
If there's no match, we'll automatically apply our smarter event-grouping algorithm to the event and create a new issue with the revamped metadata design.
This is the first big update that we're making to our event grouping. If you have feedback or encounter any issues, please let us know by filing a report.
If you're not seeing crash-free metrics (like crash-free users and sessions) and/or velocity alerts, make sure that you're using the Crashlytics SDK v10.8.0+.
If you're not seeing breadcrumb logs, we recommend checking your app's configuration for Google Analytics. Make sure you meet the following requirements:
You've enabled Google Analytics in your Firebase project.
You've enabled Data sharing for Google Analytics. Learn more about this setting in Manage your Analytics data sharing settings
You've added the Firebase SDK for Google Analytics to your app. This SDK must be added in addition to the Crashlytics SDK.
You're using the latest Firebase SDK versions for all the products that you use in your app.
Especially check that you're using at minimum the following version of the Firebase SDK for Google Analytics:
iOS+ — v6.3.1+ (v8.9.0+ for macOS and tvOS).
To upload your project's dSYMs and get verbose output, check the following:
Make sure your project's build phase contains the Crashlytics run script, which allows Xcode to upload your project's dSYMs at build time (read Initializing Crashlytics for instructions on adding the script). After updating your project, force a crash and confirm that the crash appears in the Crashlytics dashboard.
If you see a "Missing dSYM" alert in the Firebase console, check Xcode to make sure it's properly producing dSYMs for the build.
If Xcode is properly producing dSYMs, and you're still seeing missing dSYMs, it's likely the run script tool is getting stuck while uploading the dSYMs. In this case, try each of the following:
Make sure you're using the latest version of Crashlytics.
Upload the missing dSYM files manually:
- Option 1: Use the console-based "Drag and Drop" option in the dSYMs tab to upload a zip archive containing the missing dSYM files.
- Option 2: Use the
upload-symbolsscript to upload the missing dSYM files, for the provided UUIDs in the dSYMs tab.
If you continue to see missing dSYMs, or uploads are still unsuccessful, contact Firebase Support and be sure to include your logs.
If your stack traces seem to be poorly symbolicated, check the following:
If frames from your app's library lack references to your app's code, make sure that
-fomit-frame-pointerIf you see several
(Missing)frames for your app's library, check if there are optional dSYMs listed as missing (for the affected app version) in the Crashlytics dSYMs tab of the Firebase console. If so, follow the "Missing dSYM alert" troubleshooting step in the dSYMs are missing/not uploading FAQ on this page. Note that uploading these dSYMs will not symbolicate crashes that have already occurred, but this will help ensure symbolication for future crashes.
Notes allow project members to comment on specific issues with questions, status updates, etc.
When a project member posts a note, it's labeled with the email of their Google account. This email address is visible, along with the note, to all project members with access to view the note.
The following describes the access required to view, write, and delete notes:
Project members with any of the following roles can view and delete existing notes and write new notes on an issue.
- Project Owner or Editor, Firebase Admin, Quality Admin, or Crashlytics Admin
Project members with any of the following roles can view the notes posted on an issue, but they cannot delete or write a note.
- Project Viewer, Firebase Viewer, Quality Viewer, or Crashlytics Viewer
See Understand crash-free metrics.
Notes allow project members to comment on specific issues with questions, status updates, etc.
When a project member posts a note, it's labeled with the email of their Google account. This email address is visible, along with the note, to all project members with access to view the note.
The following describes the access required to view, write, and delete notes:
Project members with any of the following roles can view and delete existing notes and write new notes on an issue.
- Project Owner or Editor, Firebase Admin, Quality Admin, or Crashlytics Admin
Project members with any of the following roles can view the notes posted on an issue, but they cannot delete or write a note.
- Project Viewer, Firebase Viewer, Quality Viewer, or Crashlytics Viewer
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
Yes, you can implement Crashlytics in macOS and tvOS projects. Make sure to include v8.9.0+ of the Firebase SDK for Google Analytics so that crashes will have access to metrics collected by Google Analytics (crash-free users, latest release, velocity alerts, and breadcrumb logs).
You can now report crashes for multiple apps in a single Firebase project, even when the apps are built for different Apple platforms (e.g., iOS, tvOS, and Mac Catalyst). Previously, you needed to separate the apps into individual Firebase projects if they contained the same bundle ID.
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.