Crashcan: Building a Better Mobile Crash Analytics Platform
Article Summary
Etsy built Crashcan, their own mobile crash analytics layer on top of a third-party provider. Why not just use the vendor's dashboard?
Mobile crashes are fundamentally different from web errors: they arrive delayed, affect multiple app versions simultaneously, and lose user state. Etsy's team needed custom analysis that their external crash provider couldn't deliver, so they built a PHP-based wrapper to augment the data.
Key Takeaways
- Mobile crashes can take days or weeks to report, unlike instant web errors
- Built custom deduplication to group crashes across app versions and OS updates
- Linked crash data to internal user accounts and tooling for faster debugging
- Used MySQL, Doctrine ORM, and queue-based workers to process crash ingestion
- Monitoring gaps caused weeks-long outages before StatsD and Nagios integration
Crashcan gave Etsy the customization they needed (version range filtering, user linking, better grouping) without maintaining full crash infrastructure.
About This Article
Etsy's crash provider didn't have the filtering tools engineers needed. They couldn't search for crashes across specific version ranges like 4.0-4.4, and they couldn't connect crashes to individual user accounts to see if problems only affected sellers or buyers.
Russ Taylor's team built Crashcan using a custom MySQL schema and Doctrine ORM. This let them run complex queries that combined crash data with their internal user databases. Engineers could filter by version range and link crashes to specific users all in one place.
Crashcan gave engineers a clear view of app health. They could see which crashes happened most often, how crashes grouped by type, and which crashes were new in each version. This made it much easier to spot problematic releases without having to build a full crash reporting system from the ground up.