Issue States and Triage

To help organize issues for you and your team, you can take actions such as assigning, resolving, or ignoring issues. These actions are referred to as triaging.

An issue can be in one of three states:

  1. Unresolved: The default state for all new issues.
  2. Ignored: The issue is ignored permanently or until a condition is met to move it to the Unresolved state. Issue alerts are suppressed for ignored issues.
  3. Resolved: The issue is resolved because it was fixed. You can also mark an issue as Resolved if you don't expect it to happen again.

Issue Triage

Triaging is deciding what to do with an issue. The image below shows how issues move through different states, with the applicable labels.

Worklow for triaging issues

Triage typically involves one or more of the following actions.


You can assign issues to teams or individuals manually or let issues be automatically assign by setting up ownership rules. This allows you to route issues to the right people and helps you and your team see only relevant issues. You might also see a list of suggested assignees including the owners of suspect commits. Typically, assigning an issue to a team indicates that the team owns the issue and that they're responsible for triaging it further.

Create an issue in an external project management tool like Jira that tracks the Sentry issue, or link an existing one. Two-way sync is available for some tools. Issues linked using global integrations or internal integrations are searchable using the terms is:linked and is:unlinked.


Resolve an issue when it's fixed or you don't expect it to happen again. You can do this manually or by including the issue ID in a commit.


Ignore an issue permanently (the default action when you press the button) if it's just noise and you'll likely never care about it. Or ignore it until a condition is met, at which point it becomes Unresolved. You can also set an issue to Ignore if you're working on the issue if you don't want to keep getting alerts.


Delete an issue to remove it from the system. A new issue is created if a new instance of the issue (a new event) occurs.

Delete and Discard

Delete and discard an issue to remove it from the system. A new issue is not created even if a new instance of the issue (a new event) occurs.


Reprocessing allows you to apply source maps and debug information files to error events that have already occurred.

Issue List Tabs

The Issues page is organized into tabs, each corresponding to a filtered list of issues:

  • All Unresolved (is:unresolved): All unresolved issues, including issues that need review.
  • For Review (is:unresolved is:for_review): Issues that need to be reviewed; for-review issues are a subset of all unresolved issues.
  • Ignored (is:ignored): All ignored issues.
  • Saved Searches: Select from a set of premade and custom saved searches. The name of the tab changes based on your selection.

These different lists help you with the triaging process.

When any of the following conditions occur for an issue, that issue is is flagged for review and displayed in the For-Review tab, or Review List:

  • A new issue is created; it's labeled "New Issue"
  • A resolved issue re-occurs; it's labeled "Regression"
  • An ignored issue meets its ignore conditions; it's labeled "Unignored"

For-review issues are a subset of all unresolved issues.

You can mark issues as reviewed, and removes the reason label (the issue stays in the Unresolved state). Unlike ignoring an issue, this is a way to acknowledge that you've seen the update to the issue but don't want to ignore it; that is, you intend to fix it at some point in the future. This action is only available on issues flagged for review.

Note that resolving or ignoring an issue implicitly marks the issue reviewed.

To keep your Review List fresh, automatically marks issues as reviewed if they haven't already been reviewed after seven days.

While you can work to have zero unresolved issues ("Inbox Zero") by resolving or ignoring all issues, this usually isn't feasible for any non-trivial production application. However, it is feasible to have zero for-review issues by triaging the Review List. We recommend triaging these issues once a day to keep your issues manageable.

You can edit this page on GitHub.