Bugsnag Helps You Fix Errors In Production To Improve Software Quality And Stability

Listen to this article

Bugsnag helps fast-moving organizations monitor and fix errors in production to improve software quality and stability. Below is our recent interview with James Smith, CEO at Bugsnag:

Q: Tell us something more about the company and your history?

A: My cofounder Simon Maynard and I founded the company in 2013 with a developer-first approach for engineering teams. Our goal is to help organizations address the pressures of application development by providing tools and data to help balance code quality/stability and speed of innovation. Fundamentally, Bugsnag is the most direct way for an organization to improve software quality for its users and release new features with confidence.

Recommended: AWH Helps Its Clients Build Great Digital Products For Competitive Advantage And To Drive Impact

Q: Can you give us insights into Bugsnag’s features?

A: Our product features can be described by our four pillars: capture, prioritize, fix and improve.

We automatically capture errors and diagnostic data in any app and group errors by root cause. We then prioritize errors for customers to focus on the errors with the highest business impact, because not all errors need fixing. Finally, we help reproduce and fix the most challenging and costly errors by collecting diagnostic data to determine what was unique about the environment that may have caused a crash to happen or what user actions lead up to a crash. Our product core is focused on development teams, and our goal is to provide them with rich data to make decisions based on business impact about which bugs to fix, because you cannot fix them all.

With this rich dataset, we also reach out beyond the core developer users. For example, customer support teams will often look up a particular user in Bugsnag to get better information about a customer support issue and to see what other errors the user may have encountered.

Our newest feature is the Releases dashboard, which is designed for the release manager and the product team to help them make data-backed decisions about when to promote from beta to production, and when the team may need to slow down on adding roadmap features and pay more attention to bugs and stability. For every release of an application, we calculate a “crash rate” metric, simply the number of crashes divided by the number of sessions. This easy-to-understand metric provides a source of truth about software quality and stability. Release managers can use it to determine when a release is ready to go from beta in production. And when the application is released, the team gets immediate feedback about the quality of the release in the wild. If the crash rate metric exceeds an internal benchmark, the product team can decide to spend the next development cycle addressing errors and slow down new features until the crash rate is reduced. When a company adds Bugsnag to its stack, the existing processes become better and improved.

Q: I see you have an API. What made you take that direction, and what applications have you seen evolve from that offering?

A: Bugsnag strongly believes in making customers’ data available to them in any way they need. For example, our standard “crash rate” metric for measuring quality is based on the number of crashes per session. But some customers may find it more useful to measure crashes per transaction, in the case of an ecommerce site, or crashes per dollar revenue. Or a customer may want an overall crash rate for the application that is fairly low, but in the shopping cart have a crash rate that is much lower. The API allows users to extract Bugsnag information into their own tools to build those metrics which are specific to their business. Customers also use the API to build integrations that we haven’t thought of yet. In all of these cases, we take customer feedback including their use of our APIs to help us plan new features and integrations, some of which started with users building their own and then asking us to create supported versions.

Q: How would you convince the reader to start using Bugsnag?

A: If you run a company or an organization with internally developed applications, you are almost certainly in need of error monitoring, because broken software in production leads to wasted engineering time and lost revenue. Crashes lead to abandoned purchases, bad reviews and customer churn. The speed of development means production monitoring is now essential. And increased fragmentation of devices and browsers mean it is now impossible to test everything before release. If not properly monitored, these problems threaten stability and lead to crashes. Developer teams have many tools available to them during the development process to root out the bugs that they can test for, but once a product is launched they have almost no visibility, and rely on customer reports with minimal information to try to prioritize, reproduce and fix errors.

In the meantime, eighty four percent of users abandon an application after experiencing just two crashes. In fast moving markets, the path to success is built on leveraging tools like Bugsnag to balance speed and stability to deliver new features quickly to users without sacrificing stability and the user experience. That is what Bugsnag helps our customers achieve.

Recommended: Engineering Simulation Solution Provider SimScale Democratizes Virtual Testing In The AEC Industry

Q: What are your plans for the future?

A: We will continue to invest in support for new programming platforms and languages as they become more widely used, and more integrations with tools our customers use in their environments. One major focus this year is extending the value of Bugsnag data beyond the development team. Our first step in this, the Releases dashboard which shipped in January, extends the value of Bugsnag to the release manager and the product team to help them make better decisions about release cadence and balancing new features and stability. We built Bugsnag to capture and retain more data than other error monitoring platforms so that we can enable these kind of use cases.

In future, look for us to further enable organizations to use this data to add value to customers. For example, customer support teams could see the Bugsnag errors for particular customers and accounts right in their native tools, so when a user calls to report an issue, customer support already has the error data pulled up and ready to hand off to engineering with all the data needed to fix.

Sales teams could get a crash rate for their top accounts. Maybe the overall crash rate for an application release is good, but certain customers are having worse experiences because of their particular environment. Sales could use this information strategically to advocate for fixes for their accounts, and be ready to answer questions if customers call them rather than opening trouble tickets.

These are just some of the things we are thinking about now, as well as listening to our customers and community for enhancements and new features to our core products.