An error issue is a grouping of error events. What counts as an error varies by platform, but in general, if there's something that looks like an exception, it can be captured as an error in Sentry. Sentry automatically captures errors, uncaught exceptions, and unhandled rejections, as well as other types of errors, depending on platform. We group similar error events into issues based on a
The Issue Details page helps you to gain further insight into the source of an error issue and the impact it has on your application's users. The main area of the page displays information about a specific error event that's part of an issue. The top panel and right-hand sidebar of the page display a summary of all the error events grouped together in this issue:
While the Issue Details page displays information about a specific error event that's part of an issue, you can navigate between the events of an issue using the "Older" and "Newer" buttons. Subscribe to an error issue by clicking the bell icon and fine tune workflow notifications related to the issue in User Settings > Notifications. Just below the issue title, the event description is displayed along with an icon representing the error level of the event:
The level can be:
- Error - orange
- Info - blue
- Warning - yellow
- Fatal - red
- Debug - gray
- Sample - purple
In the right hand sidebar, sentry.io reflects a summary that includes information such as how often the error issue has occurred in the last 24 hours and the last 30 days, as well as the last time and the first time the issue was seen. If the issue is linked to any GitHub or Jira issues, that's displayed here as well. You can also use this section to link to existing GitHub or Jira issues. Learn more about linking issues in Integrations. Lastly, there is a facet map, which shows the distribution of values for the tags for all events included in the error issue. All of these values are based on the environment that you've selected in the environment dropdown.
In addition, this page provides several other key pieces of information explained below.
The trace navigator (which displays below the date) is an abbreviated view of the related trace for the current transaction. It displays up to six nodes, each representing different groups of the event's trace:
- Root: Starting transaction
- Ancestor: Events that are descendants of the root, and are directly related to the current event
- Parent: Event that directly started the current event
- This Event: Node representing the current event being viewed
- Children: Events that the current event directly started
- Descendants: Future generations of events created by children of this event
A node will be red if it is associated with errors. Click "View Full Trace" to display the Trace View.
A suspect commit is a commit that's been identified as potentially having caused the error event. If you've configured suspect commits, these are displayed. This allows you to immediately investigate commits that are likely to have generated the issue. The author of the suspect commit is also suggested as an assignee for the error issue.
Tags are key/value string pairs that are both indexed and searchable. For example, a tag provides you with information such as the browser, device, or user associated with the event. Tags are the diagnostic information sent by the SDK for the individual event.
The tags displayed in the main section of this page are specific to the event that you're viewing. In contrast, the tags displayed in the right-hand sidebar are a summary of all tag values for all events included in the issue. You can set your own tags to make them more useful for debugging as described in Customize Tags.
Sentry provides the ability to take a screenshot and include it as an attachment when a user experiences an error, an exception or a crash. Screenshot attachments sent as a part of an event are displayed in this section. This feature only applies to SDKs with a user interface. It's supported for the following SDKs:
Exception (Stack Trace)
The "Exception" section of the page displays the stack trace, which shows you the line of code that the event errored on:
It's the most important piece of information that the Sentry grouping algorithm uses to group events into one error issue. You can also customize how error events are grouped. Learn more about customized grouping in Issue Grouping.
You can set your own breadcrumbs to make them more useful for debugging.
If you’ve enabled Session Replay, you’ll see a replay preview under Breadcrumbs if there’s one associated with the frontend error event you’re viewing. This will lead you to the Replay Details page when you click it.
Tracing augments your existing error data by capturing interactions between your software systems. In the "Trace Details" section, you can click the "Search by Trace" button to see all the events that share the same trace ID.
Event Grouping Information
The "Event Grouping Information" section provides details of how Sentry fingerprinted the event into the group. You can see which parts of the stack trace contributed to the
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").