Bug fixing is a constant pressure that never lets up for engineering teams. No matter the size of your application or software team, there will be bugs. Organizations will often divide up the codebase based on team roles and rely on code ownership, but it’s inevitable some bugs will fall through the cracks. That’s why we’re excited to announce our latest feature, automatic error ownership.
Our automatic error ownership feature lets you automatically triage each error to the correct team or individual based on rules defined by you. By proactively assigning errors through automation, you know with confidence your teams are aligned and no error is left unassigned.
Through automatic error assignment, developer teams and organizations can achieve better collaboration, faster deployments, and more stable applications. Keep reading to learn how and why automatic error assignment from BugSnag not only gives your developers confidence but you as well.
Manually triaging errors can be a repetitive and potentially error-prone process, taking valuable time away from core engineering tasks. With BugSnag’s rules-based error ownership, you can create a rule once and any error that matches this rule will be assigned to a chosen team or collaborator.
These custom rules evolve error catching and triaging from a reactive process to a proactive one. Each rule in BugSnag is tailored to specific criteria selected by a Project Admin. A rule can target errors based on three types of criteria: code location, default metadata, or custom metadata. We’ll explain each one in more detail below.
As stated, our automatic error ownership engine allows you to target errors in several ways:
First, you can use an error’s location in the codebase to target errors and assign a rule. For example, using a [glob](https://linux.die.net/man/7/glob), you can target an error using the location of a file or directory.
If you have teams or individuals focused on a specific area of your codebase, this can be especially useful. Individuals will be notified when a rule is assigned to them and when an error under that rule’s jurisdiction occurs. Thus, teams can focus on errors in their jurisdiction and ignore the white noise from errors occurring in different parts of the application.
If you are unable or unsure if you wish to match an error by code location, you may instead wish to use more contextual information such as the app version, BugSnag’s context property, or even a specific user to name a few.
This is a great place to begin if code location doesn’t fully cover team or individual responsibilities. For example, many applications will have a web and mobile version, with teams focused on specific platforms. If you have a mobile application with an Android and iOS version, you’ll likely create a rule targeting ANRs that will be highly relevant to your Android platform team. On the other hand, your iOS team will give little care because these errors have no impact on them. Sorting errors via context like device type will be extremely useful in this example and similar scenarios.
Additionally, you may have a freemium app with a small subset of users who are disproportionately contributing to your revenue. You will want to prioritize these users over your free users. By targeting errors that are affecting these VIP users, you can prioritize them and be reassured these errors are assigned for immediate resolution.
Each organization has its own metadata it prioritizes in its debugging process. We have known this for a long time. It’s why BugSnag has long offered the ability to add custom metadata to errors.
This also applies to our automatic error assignment rules. When creating a rule, sometimes knowing the code location or default metadata is not enough. For these cases, BugSnag gives you the option to create rules using custom metadata.
You can target an error based on any custom metadata that you send to BugSnag along with an error. This allows you complete control in how you approach automatic error ownership.
One of the most pressing challenges with the debugging process is ensuring team alignment. While alerting, bookmarks, and filters are a common way to filter out the noise, error assignment rules take things a step further.
Project Admins in BugSnag can create and manage rules in one location for project members to view all project rules. This establishes a single source of truth about who owns what and the order precedence of rules targeting specific errors. When teams are unsure of who owns certain errors, it simplifies error prioritization and is a quick reference to know the assignee responsible for each rule.
Additionally, it can be quite easy to inadvertently have more than one rule that targets an error. Equally, you may consciously wish to have a fallback assignment rule for all errors that do not fit a rule. For example, you assign all errors in the checkout directory to James, using a glob:
Subsequently, you wish to assign all other .tsx errors in to Simon, as a fallback.
As we evaluate errors in order from top of the list to bottom, you need to ensure that you rank more specific rules higher in the list. If you were to move the **/*.tsx rule to the top of the list, all .tsx errors will always be assigned to Simon regardless of there being more specific ones below.
We all know how fast-paced agile environments can be. Should priorities change, there is no need for Project Admins to fret. Rules can easily be reprioritized with simple drag-and-drop features. Plus, there is no limit to the number of rule changes or the frequency of changes. Rules are still recorded and available for view by all Project Members, so they can stay up to date with your latest changes.
Automatic error ownership is available at no extra charge to all our Enterprise customers. If you are not currently on an Enterprise plan, please contact your sale representative to find out how you can upgrade your plan.
If you are already on an enterprise plan, then you can simply log in to BugSnag and navigate to Project settings > Automatic error assignment.