At Bugsnag, one of our main goals has always been to help you prioritize and fix the bugs that matter. The purpose of our new Alerting and Workflow Engine is exactly that.
With the new engine, you can create any set of filters in the search bar, save the set of filters as a bookmark, and use this bookmark to filter alerts in order to only receive notifications for errors that matter to you.
In the first blog of this series, we went into detail about how to make use of the new alerting capabilities to minimize noise and deliver only alerts that are relevant and actionable. In this second blog, we will focus on how you can use the new Alerting and Workflow Engine to prioritize and fix the bugs that matter to your team.
In a large or mid-sized application, different teams will contribute to different parts of the codebase. Suppose your team is one of a dozen teams, all working together on an application that makes a mobile game. Perhaps your team works on maintaining the in-app purchases feature set, while another works on the account setup up flow, and yet another works on character customization features. The team that should be notified of a bug depends on which part of the code a bug originates from. Naturally, your team has no need for notifications about errors originating from another team’s code.
Bugsnag automatically reports the stacktrace, including fields such as file and method. These fields can be used to filter for code that is under the team’s code ownership, saved as a bookmark and added to a notification. Additionally, custom filters can be used to tag any error for code ownership and similarly applied to a notification. When error notifications are being sent directly to the team who owns the code, you can streamline the triaging process and save valuable time for your Release Manager, SRE or Engineering Manager, who may be triaging these errors manually today.
Additionally, error notifications can also be useful in highlighting issues with the specific feature or A/B test group your team is working on. Custom filters can be configured based on feature flags or experiment groups which can subsequently be saved as a bookmark and associated with a notification. This will filter out the noisy alerts from parts of the application you don’t care about and make sure you are notified of every issue with the feature you’re focusing on.
Let’s illustrate with an example of how a team can leverage notifications to be notified of only the errors in their code.
Using this bookmark to filter alerts, you can ensure that the alerts you receive are relevant and actionable for your team. Once you’re aware of the bugs affecting your team without the noise of bugs that originate from another team’s codebase, you can begin to build team alignment around these bugs and prioritize them accordingly.
Stay tuned for the next blog in this series to learn about how you can leverage notifications to identify and prioritize errors affecting your most valuable customers.