As we've turned the final pages of 2023 and now set our sights on 2024, it felt like an appropriate moment to pause, reflect, and shine a light on the steps we've made over the past year at BugSplat. There are a couple of compelling reasons to do this: First, we recognize that some of our key updates might slip under the radar amidst the hustle and bustle of daily tasks. Highlighting these changes is our way of giving you a second chance to discover some useful new features at your disposal.

At BugSplat, we're always looking for ways to seamlessly integrate critical crash data into the support workflow. Another step in that quest has just been launched - the ability to automatically create defects from BugSplat databases in attached third-party trackers like Jira, Github Issues, Azure DevOps and more. This isn't just a new feature - it's a game-changer. Here's why.

Building and supporting a video game project is challenging. It is a complex and intricate process that balances difficult time constraints and ambitious goals while keeping a highly engaged and demanding user base happy. Game developers need every advantage possible in the development and support process to succeed. One of the best ways to ensure that a game is successful is to make sure that every shipped version of the game project contains as few crash-causing defects as possible.

At BugSplat, we're constantly searching for ways to help our users save time and energy while fixing crashes. We do this by providing them with more tools to quickly identify the underlying defects that cause problems in their apps. In that vein, we're excited to introduce the Batch Reprocess Tool (view technical doc here), a new feature that allows users to quickly select a set of crashes and have them reprocessed in bulk.

At BugSplat, we have a unique view of how uncaught crashes can impact individual teams (and entire companies) through our work building tools to find and fix bugs in live applications. We've seen firsthand the difference it can make when teams have a workflow for reporting every defect that makes it into production and when they don't.

BugSplat's new auto-grouping feature is a powerful way to automatically group crashes in a way that's meaningful to your team. Normally, crashes are grouped by the top of the call stack. But sometimes this grouping isn't ideal. For example, if the top of your call stack is KERNELBASE!RaiseException (a Windows OS function) you'd probably prefer the crashes were grouped by a different stack frame. That's what BugSplat's auto-grouping feature does!

Finding and fixing bugs is a critical part of the development process, both in development and production, but is it possible to be more effective in less time? A poll of thousands of software industry members conducted by Stripe revealed that the average software development team spends up to 42% (Stripe/Harris) of their time on tasks in service of fixing bugs. That's almost half of all developer time spent maintaining old code instead of writing new code.

Supporting large applications with enormous crash volumes can be a real pain in the hindquarters. It is extraordinarily difficult for organizations to optimally dispatch engineering resources without excellent data and proper tooling. At BugSplat, we recently upgraded the tooling we provide to developers so that they can group related crashes and better target their support efforts, deliver more stable applications, and deliver more value to their customers.

BugSplat recently added Crash Grouping and Aggregation in Search. Grouping crashes provides new insight into your product's stability and allows you to prioritize fixes based on a wide variety of criteria. To try out this new feature, navigate to the Crashes page.

We've just released a way to track the number of users affected by a crash! If you navigate to the Summary page, you'll now see a column labeled 'Users Affected’, this column shows how many unique users have been affected for each row in the crash summary table. With the data provided by this new column, you’ll have additional information available for prioritizing fixes. The ‘Count’ column is unchanged, and reports the total number of crashes reported by all users.