Crash Reporting

Crash reports by Crashlytics are designed to get you the answers you need quickly. Instead of just showing you the stack trace, we analyze the threads to de-prioritize lines that don’t matter while highlighting the interesting ones. This makes reading stack traces easier, faster, and more useful.

Crashes and Issues

Crashlytics aggregates crashes by source issue- particular lines of code that seem to be causing the same type of crash. If, for example, you had 30,000 crashes reported, these may be attributable to 20 source issues. Crashlytics will identify those 20 and assign them a level of severity, called an impact level.

Defining Impact Level

We rank each issue based on a number of different factors, including the number of unique users affected and the total count and frequency of the crash.

Our goal is to show you the most significant, high impact issues first. This way, you know which ones to address that will have the most positive impact on your user base. Crashlytics will also alert you if the impact level of a given issue changes.

Closing Issues

When you believe you’ve fixed an issue, you can mark is as “closed” in the Fabric dashboard. If a new crash comes in for a closed issue for that version of the app, the issue will remain closed. However, any crashes for it are still handled and added to the closed issue.

If you release a new version and it occurs again, a new issue will be created. You can choose to be notified by email if this happens.

Filtering Closed Issues

On the Issue list page, you can use filters to see all closed issues or issues for a certain version using those filters.

Searching Issues

If you’re looking for a specific crash, you can search on all user information, custom keys and logs, as well as:

• File name
• Method name
• Exception Type
• Line Number
• Issue notes

All searches by default are trailing wildcard searches and you can filter by build.