This page is a follow-up to Getting Started with Bugsnag and assumes the reader possesses a foundational understanding of the product and has, at a minimum, completed the setup process and sent a few error reports to Bugsnag. These sections include links to the product documentation and provide example use cases & benefits of the advanced features in Bugsnag. You can use this information to decide which features to utilize during your Bugsnag rollout based on whether they will help your team achieve their goals.
Bugsnag groups errors together on the inbox to minimize unnecessary noise so you can focus on the issues that are having the biggest impact on your users. Error grouping reasons are noted as a tooltip within each error report and can be customized as needed. A grouped error displays on the inbox with an event count, which tells you how many times the error occurred, as well as when it was first introduced and last seen.
An on-call engineer is notified of an error spike in one of the applications they are supporting, logs in to Bugsnag to analyze the impact of this issue, and immediately notices a huge uptick in events associated with this error over the last two weeks on the dashboard. The engineer clicks into the error report for additional diagnostics and moves it into their debugging workflow via the two-way issue tracker integration.
Searching is one of Bugsnag’s core features and gives you the power to quickly find the errors you’re looking for. When you enter a set of search criteria, that is considered a segment, and bookmarks allow you to save error segments so they can easily be returned to at a later time. Bookmarks can be saved for personal use or shared with all of the collaborators on a project to create visibility around the most important error segments.
An engineering manager is responsible for triaging the errors in Bugsnag and assigning them to the appropriate team member, based on the area of code. They consistently search for errors occurring in specific parts of the application to determine ownership of the error. By creating personal or team-shared bookmarks of the known error segments, the engineering manager only needs to enter their search criteria once – They will be able to return to this same search later, with refreshed results, by selecting the bookmark again or setting it as their default view for the project.
Custom filters are part of Bugsnag’s advanced search capabilities. While you can always filter on the diagnostic data in your error reports, custom filters allow you to search against the custom metadata sent to Bugsnag which is unique to your application or business. Custom filters are useful for quickly analyzing the performance of A/B test variants and prioritizing errors based on customer segments or subscription levels.
A/B Tests – The engineering team is ready to push an update to the company pricing page but wants to measure the performance of the new page against the old page before switching over entirely. They decide to do a staged rollout and assess the performance of each page/variant with Bugsnag by turning these attributes into custom filters and searching for newly introduced errors on the inbox or timeline.
Subscriptions – The engineering team notices an error is impacting a high number of users and while investigating, determines paid customers (ex. premium subscription) are being disproportionately affected by this issue. After filtering the dashboard or timeline for errors impacting premium customers, the engineering team is able to connect numerous errors to a bad release and revert the code changes.
Custom filters are available on Standard and Enterprise plans. See the Bugsnag pricing page for details.
The releases dashboard offers visibility into the health and stability of each version of your application. This release-centric view focuses on adoption with 24-hour session counts and provides insight about your application’s health with precise stability scores. You can integrate with supported build tools or call the build API to add release metadata and link directly to your source control from the releases dashboard.
A release manager/engineer is responsible for overseeing the latest deployment and logs in to Bugsnag to monitor the crash rate and number of errors introduced in the new version. From the releases dashboard, they can see how this release is performing (relative to previous releases) and quickly decide whether to rollback the deploy if they notice a high number of fatal sessions or low stability score.
The releases dashboard is available on Standard and Enterprise plans. See the Bugsnag pricing page for details.
Bugsnag supports user identification to help with prioritization and simplify the process of correlating errors with customer reports. The default definitions for “users” vary by platform so you’ll need to configure the notifier to send additional user information (such as names and email addresses) to Bugsnag, which will populate the “Users” tab in the error details. You can also pivot on this attribute in the error report to see a full list of users affected by the error.
Developers – An engineer monitoring Bugsnag notices an error on the inbox is impacting a high number of users and views the error details for more information. Switching to the “Users” pivot allows the engineer to investigate users who frequently experienced the error (based on % of events) and search for patterns in their diagnostic data. If the engineer decides this error has a high enough impact, they can forward the list of impacted users to Support to provide them with advanced notice of possible customer reports.
Support – The Support team receives an influx of customer tickets about a dysfunctional core feature and asks the engineering team to investigate. After checking Bugsnag, the engineering team confirms the bug and provides Support with a full list of users impacted by this issue. The Support team can use this data to prioritize their outgoing communications and link it back to their ticket counts for accurate reporting/analysis.
Breadcrumbs allow you to see the important events, user actions and database queries leading up to an error. This information populates the “Breadcrumbs” tab in the error details and resembles a log or timeline with straightforward steps to reproduce the error. Bugsnag automatically captures common events as breadcrumbs (varies by platform) but you can also attach additional diagnostic data as breadcrumbs for further insights.
A customer reports a bug to Support but provides minimal information, so the Support team is unable to reproduce the issue. An engineer or Support team member (with Bugsnag credentials) can log in to Bugsnag, filter for errors experienced by the user based on their name or email address, and examine the “Breadcrumbs” tab in the error details for exact steps to reproduce the bug.
The timeline in Bugsnag is a powerful tool for surfacing actionable information about error spikes and assessing the health of your releases. Interactive features allow you to click and drag to zoom-in on the timeline and narrow down your search to a specific window, or to change the time period by sliding the bottom scale. You can also use the timeline to pinpoint how many errors a user experienced in a specific period with searching.
An on-call engineer is notified about ongoing performance issues (error spikes) with their application and logs in to Bugsnag to investigate the problem. From the timeline, the engineer can zoom-in on the specific period (ex. when the performance issues began to the present time) to examine the errors that started spiking and potentially move these issues into the debugging workflow.
Most Bugsnag notifiers support release tracking and allow you to send the source revision when you release a new version of your application, which is annotated on the timeline. These annotations can help you determine which errors were introduced or seen in each release and track performance at a glance. Custom built notifiers, or notifiers that don’t support release tracking, can integrate via the build API.
An engineer has shipped code from staging to production and logs in to Bugsnag to proactively monitor the timeline for spikes or newly introduced errors. Using the annotation as a reference point, they can filter the timeline for events seen and introduced in the latest release. A significant error spike would be easily visible from the timeline and could warrant rolling back the code changes to debug any new errors.
Since Bugsnag was created for engineers, by engineers, you’ll find a few productivity tricks within the product that you already know by virtue of being an engineer. Utilize the available keyboard shortcuts for easy site navigation.
An engineer receives a Bugsnag notification in Slack or PagerDuty and clicks on the link to open up Bugsnag and investigate the issue. The link takes them directly to the error details, from which they can use shortcuts to navigate between pivot tables, individual events, or take actions on the error without ever leaving the comfort of their keyboard.