So, whether you’re logging into the Bugsnag Dashboard for the first time or have already created several projects, this series will help you develop a strong foundation for using Bugsnag efficiently and effectively. Let’s kick things off by talking about one of the essential pages in Bugsnag, the Bugsnag Inbox. This page houses all of an app’s crash data and can be used to visualize overall app health within a customizable timeline. The grouping logic built into Bugsnag uses the underlying root cause of a crash to group exceptions as unique events. This helps minimize noise, as well as identify the most relevant crash data in the Inbox. Bugsnag displays each grouped crash with the error headline, as well as the top stack frame where the crash occurred in the app. Below the headline is the message generated with the crash, as well as when the error was last seen and first introduced. If any users within the Bugsnag project commented on the error or were assigned ownership of the bug, that can be found next to the timestamp. 1. Error headline 2. Error message 3. Last time error was seen; First introduced 4. Error comments 5. Error assignee Error Details Moving onto the right side of the Inbox, here, the crash count of each corresponding error can be found, as well as how many users it has impacted. Clicking these parameters will sort them by total count, starting from largest to smallest. Further right is the trend bar corresponding to each error’s impact within the Inbox’s current time range setting. Adjusting the Inbox’s time range can provide insight into up to two months of historical data. Next to the trend bar is the release stage that the error occurred in—Bugsnag will display both staging and production builds if the error was seen in both. Lastly, the severity of the error is reflected furthest to the right of the Inbox. Unhandled exceptions are, by default, given an “error” level of severity, and handled exceptions are marked as a “warning.” 1. Error count  2. Trend bar  3. Release stage  4. Severity level Error Triage Lastly, looking to the left side of the Inbox, errors can be assigned to various work status bins to assist triage. When an error’s status changes, it’s placed in the corresponding status bin. For example, opening an errors status assignment box by clicking the checkmark and then marking the error as fixed will move it from the “Open” status bin to the “Fixed” bin. Using this workflow will allow team members to know that the error has been actioned, as well as keep the status bins tidy. Errors can also be assigned to various team members using an error “Assigned” status or via an issue tracker integration such as Jira. Low-priority or noisy errors can be marked as “Snoozed” until they pass a customizable threshold. Lastly, for errors that don’t need to be actioned, marking them as “Ignored” will prevent them from sending notifications. Errors can also be discarded or deleted, removing an instance of the error just once or permanently, depending on the respective action. Status bins  2. Status assignment box That concludes the overview of the Bugsnag Error Inbox, as well as part one of the Bugsnag Beginners Series. Please stay tuned for the next topic, which will dive deeply into the Error Details page. See you then!

Bugsnag Beginners' Series: Part 1 - Error Inbox

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Little Dropbox, Bugsnag, and a Lot of Visibility During Error Investigation

51 Stories To Learn About Bugs

A Little Dropbox, Bugsnag, and a Lot of Visibility During Error Investigation

A Quick Guide on Best Practices for JavaScript Error Monitoring

"Alerts need to be useful"

A Little Dropbox, Bugsnag, and a Lot of Visibility During Error Investigation

51 Stories To Learn About Bugs

A Little Dropbox, Bugsnag, and a Lot of Visibility During Error Investigation

A Quick Guide on Best Practices for JavaScript Error Monitoring

"Alerts need to be useful"

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps