Issues

Every error your applications report is an event. Events of the same error are grouped into one issue, with a count, a status and a stack trace. The issue list is where you decide what to fix next.

Grouping

Bugtail groups events like this:

With an exception: by the exception type and the top of the stack trace in your own code. Line numbers do not take part, so a deploy that moves code around does not split an issue.
Without an exception: by the message, with the parts that vary taken out. User 4821 not found and User 9 not found become one issue, because numbers, ids, quoted values, email addresses, IP addresses, dates and URLs are left out.
With a fingerprint: exactly as the fingerprint says. Every Sentry SDK lets you set one, and the HTTP format accepts it too. Events with the same fingerprint always end up in the same issue. A fingerprint of only {{ default }} keeps the default grouping.

Each issue gets a short reference from its project, such as SHOP-14, which you can search for.

Statuses

Status	Meaning
Unresolved	Seen and not dealt with yet. Every new issue starts here.
Resolved	Marked as fixed. If it happens again, it becomes Regressed.
Regressed	It was resolved and came back. Worth looking at first.
Ignored	Muted. It is hidden from the default list and triggers no alerts.

The list shows open issues by default: unresolved and regressed together.

Muting

Ignore mutes an issue until you reopen it. Two shorter options return it to the list by themselves:

Mute for a day: it comes back with the first occurrence after 24 hours.
Mute until the next release: it comes back with the first occurrence in a different release. Useful for an error you have already fixed but not yet deployed. Your events need a release for this.

Working on an issue

Assign it to a colleague, so everybody knows who is on it.
Watch it to get an email when it comes back after being resolved, whether or not an alert rule covers it.
Comment under Activity to leave what you found for the next person. Activity also shows every status change and who made it.
Select several issues in the list to resolve or ignore them at once.

Finding issues

Filter the list by project, environment, level, status and time range, and search the title, the culprit or the reference. Sort by last seen, most frequent, most users affected or newest.

Save a combination of filters as a search to come back to it. A saved search is private to you unless you share it with the team.

The issue page

The issue page shows an event in full: the stack trace, the breadcrumbs, the request, tags and extra data, and where it happened (release, environment, server, browser and page). When the event happened during a traced request, you can open that trace from here.

Counts on an issue keep going after its individual events have passed their retention period. An old issue can therefore show a large count and no events. See Data and privacy.

Breadcrumbs

Breadcrumbs are what happened just before the error: clicks, navigation, requests, log messages. SDKs record them automatically, and the issue page shows them as a trail leading up to the error.