At BugSplat, we've been supporting applications and video games with crash and error reporting for a long time. Over the years, we've collaborated with a wide range of teams, handling applications of all sizes.

From our experience and numerous conversations with users, we've noticed an interesting trend: the distribution of crashes isn't uniform.

If your application experiences 100 crashes in a given version, those crashes aren't caused by 100 different defects. Instead, a large percentage of crashes stem from a relatively small number of defects. Identifying and fixing these critical defects is the most efficient way to significantly improve your application's stability.

In fact, these defects-to-crashes roughly follow the famous 80/20 rule, also known as the Pareto principle. Sometimes, the distribution is even more extreme, with 10%, 5%, or even 1% of defects causing the majority of user crashes.

What stands out is that efficiently identifying and addressing these key defects can greatly enhance your code's stability, saving you substantial time and resources.

In other words, there's a lot of time, energy, and budget to be saved and reapplied if you can successfully identify your top ~20% of defects.

Identifying the 20% with BugSplat

To help you better identify and address the top ~20% of bugs causing the lion's share of crashes, here are some technical suggestions for dialing in your BugSplat integration:

  1. Collect Crashes and Errors in Production: Ensure your production environment is configured to report crashes and errors. This data is crucial for understanding how your application behaves under real-world conditions.
  2. Use Crash Grouping Effectively: Make sure you are taking full advantage of BugSplat's crash grouping features. Grouping crashes by type, stack trace similarity, and other criteria helps you quickly identify the most frequent issues.
  3. Analyze Trends on the Summary Page: Regularly review the Summary page to identify trends and outliers in your crash data. This page provides an overview of the most critical defects and their impact, helping you prioritize your efforts effectively.
  4. Set Up Automated Notifications: Configure automated notifications for critical crashes. This ensures that your team is immediately aware of significant issues and can respond promptly.
  5. Integrate with Your Workflow: Use BugSplat's integrations with tools like Jira, Slack, and GitHub to streamline your workflow.
  6. Leverage Real-Time Updates: Enable real-time updates to stay informed about new crashes as they occur.
  7. Advanced Search and Filtering: Use BugSplat's advanced search and filtering capabilities to dig deeper into your crash data.
  8. Utilize Custom Attributes: Leverage custom attributes to add context to your crash reports.

Find your top 20%, and the rest of your stability work gets a lot cheaper.

But "top 20%" isn't just "most frequent." That's the part teams get wrong. Raw crash count is a starting point, not a priority list. The crash that fires 10,000 times but recovers cleanly and dumps you back at the menu is annoying. The one that hits 200 players and eats their save file is a refund and a bad review. Sort by frequency first, then ask the questions frequency can't answer: how bad is it when it happens, who's it happening to, and did it just start?

That last one matters more than people think. A defect that's been quietly throwing the same 50 crashes a day for a year is a known quantity. A new defect throwing 50 a day that wasn't there last build is a regression, and it's probably tied to something you just shipped. Same count, very different urgency. This is where BugSplat's filtering earns its keep - slice by build, platform, or custom attribute and the real priorities separate from the noise fast.

A caveat, because the 80/20 rule can quietly become an excuse. It's a triage tool, not a finish line. The long tail comes due eventually - usually at the worst time. Cert submission, a platform holder's crash-rate threshold, or the one enterprise customer whose weird edge-case crash is the only thing standing between you and renewal. The 20% buys you the biggest stability jump for the least effort. It doesn't buy you a pass on everything else, and the teams who pretend it does tend to find out during a submission window.

But the order is right. Knock out the handful of defects driving the majority of your crashes, and you've turned a wall of 10,000 reports into a short list you can actually act on. Everything after that is cleanup - and cleanup is a much nicer problem than triage.

More on crash reporting over on the BugSplat blog.If your app throws 100 crashes in a release, those crashes aren't 100 different bugs. After years of crash data across teams of every size, we see the same shape almost every time: a handful of defects cause the overwhelming majority of crashes.

It roughly follows the Pareto principle - 20% of the defects, 80% of the crashes - and it's often steeper than that. Sometimes 5% of your bugs are doing 90% of the damage.

The upside is obvious: find and fix that top slice, and you get a disproportionate jump in stability for the effort. That's real time and budget back in your pocket.

Here's how to dial in your BugSplat integration to surface that 20% fast:

  1. Collect crashes in production - real-world conditions are where the defects that matter actually show up.
  2. Lean on crash grouping - grouping by stack trace similarity collapses thousands of reports into the few defects behind them.
  3. Watch the Summary page - it ranks your most impactful defects so you know what to fix first.
  4. Set up notifications - get pinged the moment a critical crash spikes, in real time.
  5. Wire it into your workflow - push straight to Jira, Slack, or GitHub so fixes don't stall in handoff.
  6. Search and filter aggressively - narrow by build, platform, or custom attribute to isolate exactly what you're chasing.

Find your top 20%, and the rest of your stability work gets a lot cheaper.

But "top 20%" isn't just "most frequent." That's the part teams get wrong. Raw crash count is a starting point, not a priority list. The crash that fires 10,000 times but recovers cleanly and dumps you back at the menu is annoying. The one that hits 200 players and eats their save file is a refund and a bad review. Sort by frequency first, then ask the questions frequency can't answer: how bad is it when it happens, who's it happening to, and did it just start?

That last one matters more than people think. A defect that's been quietly throwing the same 50 crashes a day for a year is a known quantity. A new defect throwing 50 a day that wasn't there last build is a regression, and it's probably tied to something you just shipped. Same count, very different urgency. This is where BugSplat's filtering earns its keep - slice by build, platform, or custom attribute and the real priorities separate from the noise fast.

A caveat, because the 80/20 rule can quietly become an excuse. It's a triage tool, not a finish line. The long tail comes due eventually - usually at the worst time. Cert submission, a platform holder's crash-rate threshold, or the one enterprise customer whose weird edge-case crash is the only thing standing between you and renewal. The 20% buys you the biggest stability jump for the least effort. It doesn't buy you a pass on everything else, and the teams who pretend it does tend to find out during a submission window.

But the order is right. Knock out the handful of defects driving the majority of your crashes, and you've turned a wall of 10,000 reports into a short list you can actually act on. Everything after that is cleanup - and cleanup is a much nicer problem than triage.

More on crash reporting over on the BugSplat blog.