Triage

When opening the Web Console, you will default to the Triage tool for the selected project. The Triage tool displays crashes or errors grouped by fingerprint (a hash that is generated when processing crashes through Backtrace's deduplication algorithms). The fingerprint is used to signify a unique error with a common root cause. The Triage tool allows you to filter down which errors (fingerprints) you want to view, provides aggregate information about the fingerprint, and enables actions to take to support resolution of the fingerprint. The following actions are available for users to take on fingerprints:

  • Assign - The fingerprint can be assigned to a user in Backtrace to indicate there is a user that is responsible to resolve it. 
  • Link to Issue - A user can create a new issue in a 3rd party system like Jira or GitHub Issues that is populated with some information about the fingerprint, and a link back to more details about the fingerprint in Backtrace.
  • Comment and Tag- A comment thread is available in the Details view of a fingerprint. Tags can be applied to fingerprints for more ad-hoc grouping and classification.  
  • Mute or Resolve - You can take explicit Mute or Resolve actions on a fingerprint. 
  • Merge / Unmerge - If you find 2 or more fingerprints that should really be grouped together, take the Merge action to create a new fingerprint to group future incoming errors into.

The remainder of this documentation will discuss how to work within the Triage tool with a review of filters, a discussion on how to navigate the result list, and more details on how to apply actions.

Filters

Review the new Web Console Overview for more general information about how to apply filters based on system or customer metadata, the set of powerful operators available, and the time range filters you can apply from the Global Header. 

You can also use the Saved View button to save and load commonly used filters, like those that allow you to view errors from Released vs Development builds.

In the Triage tool, you'll notice shortcuts to apply Open, In Progress, Resolved, Muted or All state filters. These states help engineering managers and engineers know which crashes need analysis, which are being actively worked on, which are resolved, and which can be ignored or muted. There is also a shortcut for "Assigned to me" to view crashes that are assigned to the current user.

We normally see engineering managers start with Open fingerprints so that they can make sure relevant issues are disposed of properly (Assigned, Linked to Jira issue, Resolved, or Muted)

Result List

After you have selected appropriate filters, you'll be presented with a result list of that is full of information. Let's dive in:

First, at the top of the list, you'll see some informational text that tells you how many issues are being displayed and how many in total there are. This gives you a view of how many additional crashes or errors that are identified outside the filter window.

For each fingerprint in the result list you can view and modify data:

  • View and modify the state from Open/In Progress to Resolved and Muted.
  • View crash or error ID of the fingerprint and head of the call stack. 
  • View the number of occurrences and number of impacted hosts or users, and activity history.
  • View system applied tags (classifiers), and manage custom tags.
  • View and manage assignees and linked tickets.
  • Select multiple fingerprints to take the merge action, or other bulk actions, such as assignment, mute, or resolve.
  • View a Details page for more exploration or the fingerprint

Click on the head of a call stack in the result list, to open a full page view of the call stack. You can copy the call stack to the clipboard, or click on any line in the call stack to apply additional filters to the result set.

A note on Open, In Progress, Resolved and Muted states:

  • Fingerprints can be marked as Resolved or Muted using the state column. If a fingerprint is marked as Resolved or Muted, it will stay in that state until it either seen again (Resolved) or if it is seen after some period of time (Muted). 
  • A fingerprint is Open if there are no assignees or linked tickets (and has not been marked as Resolved or Muted). The act of assigning a fingerprint or linking it to an issue will cause the Open fingerprint to be listed as In Progress. By the same notion, a fingerprint that is In Progress and has its assignees removed and tickets unlinked will be listed as Open.

Details Page

Click on a result in the result list to open a detailed view of fingerprint. You will also have the ability to add attributes to the detailed view of the fingerprint so you can see how values are distributed amongst the set of crash occurences.

Actions

This section will discuss the actions you can take on a fingerprint.

Assign

The fingerprint can be assigned to a user in Backtrace to indicate there is a user that is responsible to resolve it. This action also sets the state of the fingerprint to In Progress.

Link to Issue

A user can create a new issue in a 3rd party system like Jira or GitHub Issues that is populated with some information about the fingerprint, and a link back to more details about the fingerprint in Backtrace. This action also sets the state of the fingerprint to In Progress. Find more details in Integrating with Jira and Other Issue Tracking Software

Comments (Coming Soon) and Tags

A comment thread will be available in the Details view of a fingerprint soon. Users will be able to post and edit their comments to assist in the resolution flow. Tags can be applied to fingerprints for more ad-hoc grouping and classification.  

Mute or Resolve

You can take explicit Mute or Resolve actions on a fingerprint. Mute a fingerprint when you don't want it to appear as Open or In Progress any more. Mark as Resolved when you think the issue is fixed and want it to be re-opened if it occurs again.

Merge / Unmerge

If you find 2 or more fingerprints that should really be grouped together, take the Merge action to create a new fingerprint to group future incoming errors into.

Did this answer your question?