Getting the most out of Crashlytics

Crash reporting is an invaluable tool and with the assortment of crash reporting tools to choose from, there isn’t any reason your app shouldn’t taking advantage of them. Even the most basic integration of Crashlytics provides extraordinary insight into how your application is behaving in the wild. However, what if we went beyond the basic setup? With a bit more configuration, we can obtain a greater Return On Investment (ROI) from our crash reporting implementation and gain more insights into our application.

Tip #1 — Include the state of the codebase in your error reports

Performing Root Cause Analysis (RCA) for an issue within an application is hard enough when you know the exact commit where the issue is occurring. But what if you get a new crash report on a version of the app you pushed out months ago? Let’s remove any ambiguity from our error reporting by including the Git Hash of the code in which the exception actually occurred. Custom Keys, which allows you to include key/value pairs with your crash reports, is the perfect solution for adding the Git Hash to the error report.

First set up your build.gradle to include the Git Hash in your BuildConfig file.

And then in your app’s application class (or wherever you were previously initializing your Crashlytics instance), include the custom keys.

And this is the final result in the Fabric Dashboard.

As you can see, I also like to include the build time meta-data to obtain a bit more context. Feel free to include as much information that you think you feel would be valuable.

Tip #2 — Log Non-Fatal Events

During development, whenever your app enters an unexpected state, you should throw an exception. There are various reasons for entering such state e.g. malformed network data, misunderstanding of requirements, a logic error. As a responsible developer you should determine the root cause of the issue and in the Software Development LifeCycle (SDLC) nothing turns heads faster than a crash. In production, however, you should balance a good user experience with the need to quickly determine the root cause of an issue. A good way to handle this is by logging non-fatal errors, which allows you to fail gracefully while still being made aware of the error.

It’s as simple as keying off of your BuildConfig and crashing for debug builds or just logging the exception on production.

Tip #3 — Leave some breadcrumbs

So now you know the exact commit the issue occurred on and you’re also monitoring for unexpected states and failing gracefully. But there is still a piece of the puzzle missing — the reproduction steps. I can’t tell you how many times I’ve stared at a stack trace having no idea how to reproduce it. Let’s leave some breadcrumbs — marks that we can use to determine the user behavior. You can do this by using your current event tracking implementation, and the Crashlytics.log(String message) method. Essentially, you’ll be able to build a log of the various events the user triggered before running into the failure.

It is as simple as properly formatting the values sent in for your analytics .and then logging it to Crashlytics.

And in the Fabric dashboard…

And that’s it! Hopefully by adding the git commit, logging non-fatal errors and leaving a trail of breadcrumbs behind you can gain even more insight into issues your users are facing and build a better product!

Do you have some awesome crash reporting tips of your own? If so, then please feel free to reach out to me and share!