From 0c867b2214a2a16a71be3c8cd95ce7dccbca0ef0 Mon Sep 17 00:00:00 2001 From: Nick Meisenheimer Date: Mon, 24 Aug 2026 16:15:10 -0400 Subject: [PATCH 1/4] docs(issues): add Inbox and issue progress states page Documents the experimental Inbox under Issues: the two-pane layout, progress sections, assignee filter, resize handle, and preview pane. Adds a subsection covering the five issue.progress states, how progress advances and falls back, Autofix interaction, and searching by progress. Co-Authored-By: Claude Opus 5 (1M context) --- docs/product/issues/inbox/index.mdx | 137 ++++++++++++++++++++++++++++ docs/product/issues/index.mdx | 4 +- 2 files changed, 140 insertions(+), 1 deletion(-) create mode 100644 docs/product/issues/inbox/index.mdx diff --git a/docs/product/issues/inbox/index.mdx b/docs/product/issues/inbox/index.mdx new file mode 100644 index 00000000000000..4e744d6384ac54 --- /dev/null +++ b/docs/product/issues/inbox/index.mdx @@ -0,0 +1,137 @@ +--- +title: Inbox +sidebar_order: 8 +description: >- + Learn how to use the Inbox to work through the issues that are closest to + being fixed. +--- + + + +Inbox is an experimental feature. It's available to organizations with [Seer](/product/ai-in-sentry/seer/) enabled, and both its behavior and its appearance may change. + + + +The **Inbox** is a focused worklist for the issues you're responsible for. Instead of sorting a long feed by date or event volume, the Inbox groups your open issues by how far along they are toward a fix, so you can start with the ones closest to done. + +You'll find it in the sidebar under **Issues > Inbox**. The number next to the link counts the unresolved issues assigned to (or suggested for) you that are in the **Assigned**, **Diagnosed**, or **Fix Proposed** state. + +## What the Inbox Shows + +The Inbox is a two-pane layout. The list of issues is on the left, and a preview of the selected issue is on the right. On a small screen, the panes stack: you see the list, then the preview after you select an issue, with a **Back to inbox** link to return. + +The list only includes **unresolved** issues in the categories Seer can work on: error, mobile, frontend, database query, HTTP client, and configuration. Resolved and archived issues never appear, and neither do categories outside that list, such as uptime outages and cron failures. + +### Progress Sections + +Issues are grouped into collapsible sections, one per [progress state](#issue-progress-states), ordered so that the issues closest to being fixed come first: + +| Section | What's in it | +| ---------------- | -------------------------------------------------------------------------------- | +| **Fix Proposed** | Issues with an open pull request that references the issue. Expanded by default. | +| **Diagnosed** | Issues where Seer has identified a root cause. Expanded by default. | +| **Assigned** | Issues that have an assignee but no root cause or pull request yet. | +| **Identified** | Everything else — open issues that no one has picked up. | +| **Fix Applied** | Issues with a merged fix that haven't been resolved yet. | + +Each section header shows a progress marker and a count of matching issues. Click a header to expand or collapse the section; **Assigned**, **Identified**, and **Fix Applied** start collapsed. Sections load 10 issues at a time — use **Show more** at the bottom of a section to load the next batch. + +### Issue Cards + +Each issue in the list is a card showing: + +- A dot on the left if you haven't seen the issue yet +- The issue title and message +- The project avatar and the issue's short ID +- How long the issue has been in its current progress state (hover to see which state it changed to) +- The assignee's avatar, if the issue is assigned + +Click a card to load that issue in the preview pane. + +## Controls + +There are two controls on the Inbox itself. Everything else you do from here happens in the preview pane. + +### Assignee Filter + +The segmented control in the list header scopes every section to a set of issues: + +- **Me** — Issues assigned to you, or suggested for you by [ownership rules](/product/issues/ownership-rules/) and [suspect commits](/product/issues/suspect-commits/). This is the default. +- **My Teams** — Adds issues assigned to or suggested for any team you're on. +- **All** — Every issue in the organization, regardless of assignment. + +### Resize Handle + +Drag the divider between the two panes to resize the issue list. Your choice is saved in the browser, so the Inbox opens at the same width next time. Double-click the handle to reset it to the default width. + +## The Preview Pane + +The preview pane shows enough of an issue to decide what to do next without leaving the page. Opening an issue in the preview marks it as seen. Click the open icon next to the title to go to the full [Issue Details](/product/issues/issue-details/) page. + +The preview includes: + +- **Header** — Issue title and message, current [status](/product/issues/states-triage/), event and user counts, and when the issue was first and last seen. +- **Actions** — Seer actions such as **Find Root Cause**, **Make a Plan**, **Write a Code Fix**, **Create PR**, and **Continue in Seer**, which reflect where Autofix has gotten to on this issue. If Seer isn't available for the issue, you get the standard issue actions (resolve, archive, and so on) instead. +- **Priority and assignee** — Change the issue's [priority](/product/issues/issue-priority/) or reassign it in place. +- **Linked pull requests** — Any pull requests that reference the issue. +- **Autofix summary** — Seer's root cause, plan, and proposed code changes, when they exist. +- **Activity** — The issue's activity feed, where you can leave a comment and tag teammates with `@` or teams with `#`. + +## Issue Progress States + +Issue progress describes how close an open issue is to being resolved. It applies only to open issues — resolved and archived issues have no progress state. + +Progress is a ladder, and the highest applicable state wins. Many issues move through all five states in order (**Identified** → **Assigned** → **Diagnosed** → **Fix Proposed** → **Fix Applied**), but skipping states is common. A brand new issue that already has a linked, merged pull request goes straight to **Fix Applied**. + +| Progress | Condition | +| ---------------- | -------------------------------------------------------------------------------------- | +| **Fix Applied** | A resolving pull request has been merged, but the issue isn't resolved yet. | +| **Fix Proposed** | At least one open pull request references the issue (for example, `Fixes SENTRY-123`). | +| **Diagnosed** | Seer identified a root cause. | +| **Assigned** | The issue has an assignee. | +| **Identified** | None of the conditions above apply. | + +### How Progress Changes + +Progress is recalculated as things happen to the issue: + +| What happens | Effect on progress | +| ------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | +| The issue is assigned | Advances to at least **Assigned**. | +| The issue is unassigned | Falls back to **Identified**, unless a root cause or pull request keeps it higher. | +| Seer identifies a root cause | Advances to at least **Diagnosed**. | +| A resolving pull request is opened or reopened | Advances to **Fix Proposed**. | +| The last open pull request is closed or unlinked | Falls back to **Diagnosed**, **Assigned**, or **Identified**. | +| A resolving pull request is merged | Advances to **Fix Applied**. | +| Anything else, while the issue is open and already **Fix Applied** | Stays **Fix Applied**. | +| The issue is resolved or archived | The issue closes and no longer has a progress state. | +| A closed issue is unresolved, regresses, or escalates | The issue reopens and its progress is recalculated. | + +A few behaviors are worth calling out: + +- Assignment survives closing and reopening an issue. +- Manually reopening an issue preserves the root cause Seer identified. +- A regression clears the root cause before recalculating progress. +- An open resolving pull request survives closing the issue and can restore **Fix Proposed** when the issue reopens. + +For example, an issue that gets a resolving pull request, has it merged, and then gets resolved in a commit reaches **Fix Proposed**, then **Fix Applied**, then closes with no progress state. If it later regresses, it reopens at **Identified**, because the regression cleared the root cause and no higher condition still applies. + +### Autofix and Progress + +Autofix steps move the issue along, but only up to a point. Recording a root cause moves an issue to **Diagnosed**; writing a plan and generating code changes don't advance it further on their own. It's the resolving pull request that moves the issue to **Fix Proposed**. + +If that pull request is closed without merging, progress falls back — usually to **Diagnosed**, since Autofix recorded a root cause on the way there, or to **Assigned** or **Identified** if it didn't. A merged pull request behaves differently: it moves the issue to **Fix Applied**, which sticks for as long as the issue stays open. + +When an issue has more than one resolving pull request, progress reflects whether _any_ of them is still open. Closing one while another remains open leaves the issue at **Fix Proposed**. Only when the last open pull request closes without merging does progress fall back. + +### Searching by Progress + +Progress is available as the `issue.progress` search property on the **Issues** page, so you can build [issue views](/product/issues/issue-views/) around it. You can also sort the issue stream by progress. + +``` +is:unresolved issue.progress:fix_proposed +``` + +``` +is:unresolved issue.progress:[diagnosed,fix_proposed] assigned_or_suggested:me +``` diff --git a/docs/product/issues/index.mdx b/docs/product/issues/index.mdx index f37a6b5ebfbd2e..98e617b1574694 100644 --- a/docs/product/issues/index.mdx +++ b/docs/product/issues/index.mdx @@ -54,13 +54,15 @@ Sentry creates issues for more than just errors. The **Issues** page sidebar gro From the **Issues** page, you can begin to triage. The page is organized into tabs, each corresponding to a filtered list of issues, and these different lists help you with triaging: - All Unresolved (`is:unresolved`): All unresolved issues, including issues that need review. -- For Review (`is:unresolved is:for_review`). Also called **Review List**, for-review issues are a subset of all unresolved issues and can include new issues or regressions that haven't been reviewed yet. +- For Review (`is:unresolved is:for_review`). Also called **Review List**, for-review issues are a subset of all unresolved issues and can include new issues or regressions that haven't been reviewed yet. - Regressed (`is:regressed`): All regressed issues; resolved issues that have come up again. - Archived (`is:archived`): All archived issues. - Escalating (`is:escalating`): All escalating issues; previously archived issues that have exceeded their forecasted event volume. Learn more about triaging issues and their different states in [Issue States and Triage](/product/issues/states-triage/). +If your organization has Seer, the [**Inbox**](/product/issues/inbox/) offers a different way to triage: it groups the issues assigned to you by how close they are to being fixed, so you can start with the ones that need the least work to finish. + ## How to Sort Issues Change how issues are sorted in the issues stream by selecting from the sort dropdown: From 4058baf9067c45f31c30128e6efeefff9a111c80 Mon Sep 17 00:00:00 2001 From: Nick Meisenheimer Date: Tue, 25 Aug 2026 14:37:21 -0400 Subject: [PATCH 2/4] docs(issues): tighten Inbox page structure and formatting Restructures the Inbox page around what the view shows and how progress changes, drops the searchable-properties section, and uses code style consistently for the five progress state names. Co-Authored-By: Claude Opus 5 (1M context) --- docs/product/issues/inbox/index.mdx | 117 +++++++++------------------- 1 file changed, 38 insertions(+), 79 deletions(-) diff --git a/docs/product/issues/inbox/index.mdx b/docs/product/issues/inbox/index.mdx index 4e744d6384ac54..6047ff2c7bcd36 100644 --- a/docs/product/issues/inbox/index.mdx +++ b/docs/product/issues/inbox/index.mdx @@ -8,102 +8,73 @@ description: >- -Inbox is an experimental feature. It's available to organizations with [Seer](/product/ai-in-sentry/seer/) enabled, and both its behavior and its appearance may change. +Inbox is newly available to organizations with [Seer](/product/ai-in-sentry/seer/) enabled and may change. -The **Inbox** is a focused worklist for the issues you're responsible for. Instead of sorting a long feed by date or event volume, the Inbox groups your open issues by how far along they are toward a fix, so you can start with the ones closest to done. +The **Inbox** view is where you manage issues you're responsible for. The Inbox sorts your open issues based on their progress toward a fix and shows you actionable next steps for driving the issues forward. -You'll find it in the sidebar under **Issues > Inbox**. The number next to the link counts the unresolved issues assigned to (or suggested for) you that are in the **Assigned**, **Diagnosed**, or **Fix Proposed** state. +You can find the Inbox by navigating to **Issues > Inbox**. The number next to the link in the inner nav shows you the count of unresolved issues that are in an `Assigned`, `Diagnosed`, or `Fix Proposed` state where you are the assignee or suggested assignee. ## What the Inbox Shows -The Inbox is a two-pane layout. The list of issues is on the left, and a preview of the selected issue is on the right. On a small screen, the panes stack: you see the list, then the preview after you select an issue, with a **Back to inbox** link to return. +The Inbox is a two-pane layout (similar to the User Feedback view). The left side shows a list of issues relevant to you, or your teams; the right side includes a preview of the selected issue with relevant details about Seer autofix, linked PRs, as well as relevant activity and comments. -The list only includes **unresolved** issues in the categories Seer can work on: error, mobile, frontend, database query, HTTP client, and configuration. Resolved and archived issues never appear, and neither do categories outside that list, such as uptime outages and cron failures. +The list only includes `unresolved` issues in the categories Seer can work on: error, mobile, frontend, database query, HTTP client, and configuration. Resolved and archived issues never appear, and neither do categories outside that list, such as uptime outages and cron failures. -### Progress Sections +### Issue Progress -Issues are grouped into collapsible sections, one per [progress state](#issue-progress-states), ordered so that the issues closest to being fixed come first: +Issues are grouped by their progress state into collapsible sections, sorted so that the mostly recently progressed issues closest to being fixed are at the top of the list. -| Section | What's in it | -| ---------------- | -------------------------------------------------------------------------------- | -| **Fix Proposed** | Issues with an open pull request that references the issue. Expanded by default. | -| **Diagnosed** | Issues where Seer has identified a root cause. Expanded by default. | -| **Assigned** | Issues that have an assignee but no root cause or pull request yet. | -| **Identified** | Everything else — open issues that no one has picked up. | -| **Fix Applied** | Issues with a merged fix that haven't been resolved yet. | +Progress is a ladder, and the highest applicable state is applied to the issue. An issue move through all five states in order (`Identified` → `Assigned` → `Diagnosed` → `Fix Proposed` → `Fix Applied`), but skipping states is expected and allowed. -Each section header shows a progress marker and a count of matching issues. Click a header to expand or collapse the section; **Assigned**, **Identified**, and **Fix Applied** start collapsed. Sections load 10 issues at a time — use **Show more** at the bottom of a section to load the next batch. - -### Issue Cards - -Each issue in the list is a card showing: - -- A dot on the left if you haven't seen the issue yet -- The issue title and message -- The project avatar and the issue's short ID -- How long the issue has been in its current progress state (hover to see which state it changed to) -- The assignee's avatar, if the issue is assigned - -Click a card to load that issue in the preview pane. - -## Controls +| Section | Condition | +| ---------------- | -------------------------------------------------------------------------------------- | +| `Fix Proposed` | At least one open pull request references the issue (for example, `Fixes SENTRY-123`). | +| `Diagnosed` | Seer identified a root cause. | +| `Assigned` | The issue has an assignee. | +| `Identified` | Open issues that no one has picked up. | +| `Fix Applied` | A resolving pull request has been merged, but the issue isn't resolved yet. | -There are two controls on the Inbox itself. Everything else you do from here happens in the preview pane. +Each section header shows a corresponding progress marker and a count of matching issues. Click a section's header to expand or collapse the section, each section loads 10 issues at a time, you can use **Show more** at the bottom of a section to load additional issues. -### Assignee Filter +An issue moves between these sections on its own as work happens. See [How Progress Changes](#how-progress-changes) for the full set of events that advance or roll back an issue's progress. -The segmented control in the list header scopes every section to a set of issues: +### Filters -- **Me** — Issues assigned to you, or suggested for you by [ownership rules](/product/issues/ownership-rules/) and [suspect commits](/product/issues/suspect-commits/). This is the default. -- **My Teams** — Adds issues assigned to or suggested for any team you're on. -- **All** — Every issue in the organization, regardless of assignment. +The toggle at the top of the list controls which issues are shown in the list: -### Resize Handle +- **Me**: Issues assigned to you, or suggested for you. +- **My Teams**: Issues assigned to or suggested for any team you're on. +- **All**: Every assigned issue in the organization. -Drag the divider between the two panes to resize the issue list. Your choice is saved in the browser, so the Inbox opens at the same width next time. Double-click the handle to reset it to the default width. +Learn more about automated assignment by checking out [ownership rules](/product/issues/ownership-rules/) and [suspect commits](/product/issues/suspect-commits/). -## The Preview Pane +### The Preview Pane -The preview pane shows enough of an issue to decide what to do next without leaving the page. Opening an issue in the preview marks it as seen. Click the open icon next to the title to go to the full [Issue Details](/product/issues/issue-details/) page. +The preview pane is limited to only the details of an issue required to decide what to do next without leaving the page. Opening an issue in the preview marks it as seen. Click the open icon next to the title to go to the full [Issue Details](/product/issues/issue-details/) page. The preview includes: -- **Header** — Issue title and message, current [status](/product/issues/states-triage/), event and user counts, and when the issue was first and last seen. - **Actions** — Seer actions such as **Find Root Cause**, **Make a Plan**, **Write a Code Fix**, **Create PR**, and **Continue in Seer**, which reflect where Autofix has gotten to on this issue. If Seer isn't available for the issue, you get the standard issue actions (resolve, archive, and so on) instead. - **Priority and assignee** — Change the issue's [priority](/product/issues/issue-priority/) or reassign it in place. - **Linked pull requests** — Any pull requests that reference the issue. - **Autofix summary** — Seer's root cause, plan, and proposed code changes, when they exist. - **Activity** — The issue's activity feed, where you can leave a comment and tag teammates with `@` or teams with `#`. -## Issue Progress States - -Issue progress describes how close an open issue is to being resolved. It applies only to open issues — resolved and archived issues have no progress state. - -Progress is a ladder, and the highest applicable state wins. Many issues move through all five states in order (**Identified** → **Assigned** → **Diagnosed** → **Fix Proposed** → **Fix Applied**), but skipping states is common. A brand new issue that already has a linked, merged pull request goes straight to **Fix Applied**. - -| Progress | Condition | -| ---------------- | -------------------------------------------------------------------------------------- | -| **Fix Applied** | A resolving pull request has been merged, but the issue isn't resolved yet. | -| **Fix Proposed** | At least one open pull request references the issue (for example, `Fixes SENTRY-123`). | -| **Diagnosed** | Seer identified a root cause. | -| **Assigned** | The issue has an assignee. | -| **Identified** | None of the conditions above apply. | - -### How Progress Changes +## How Progress Changes Progress is recalculated as things happen to the issue: | What happens | Effect on progress | | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | -| The issue is assigned | Advances to at least **Assigned**. | -| The issue is unassigned | Falls back to **Identified**, unless a root cause or pull request keeps it higher. | -| Seer identifies a root cause | Advances to at least **Diagnosed**. | -| A resolving pull request is opened or reopened | Advances to **Fix Proposed**. | -| The last open pull request is closed or unlinked | Falls back to **Diagnosed**, **Assigned**, or **Identified**. | -| A resolving pull request is merged | Advances to **Fix Applied**. | -| Anything else, while the issue is open and already **Fix Applied** | Stays **Fix Applied**. | +| The issue is assigned | Advances to at least `Assigned`. | +| The issue is unassigned | Falls back to `Identified`, unless a root cause or pull request keeps it higher. | +| Seer identifies a root cause | Advances to at least `Diagnosed`. | +| A resolving pull request is opened or reopened | Advances to `Fix Proposed`. | +| The last open pull request is closed or unlinked | Falls back to `Diagnosed`, `Assigned`, or `Identified`. | +| A resolving pull request is merged | Advances to `Fix Applied`. | +| Anything else, while the issue is open and already `Fix Applied` | Stays `Fix Applied`. | | The issue is resolved or archived | The issue closes and no longer has a progress state. | | A closed issue is unresolved, regresses, or escalates | The issue reopens and its progress is recalculated. | @@ -112,26 +83,14 @@ A few behaviors are worth calling out: - Assignment survives closing and reopening an issue. - Manually reopening an issue preserves the root cause Seer identified. - A regression clears the root cause before recalculating progress. -- An open resolving pull request survives closing the issue and can restore **Fix Proposed** when the issue reopens. +- An open resolving pull request survives closing the issue and can restore `Fix Proposed` when the issue reopens. -For example, an issue that gets a resolving pull request, has it merged, and then gets resolved in a commit reaches **Fix Proposed**, then **Fix Applied**, then closes with no progress state. If it later regresses, it reopens at **Identified**, because the regression cleared the root cause and no higher condition still applies. +For example, an issue that gets a resolving pull request, has it merged, and then gets resolved in a commit reaches `Fix Proposed`, then `Fix Applied`, then closes with no progress state. If it later regresses, it reopens at `Identified`, because the regression cleared the root cause and no higher condition still applies. ### Autofix and Progress -Autofix steps move the issue along, but only up to a point. Recording a root cause moves an issue to **Diagnosed**; writing a plan and generating code changes don't advance it further on their own. It's the resolving pull request that moves the issue to **Fix Proposed**. - -If that pull request is closed without merging, progress falls back — usually to **Diagnosed**, since Autofix recorded a root cause on the way there, or to **Assigned** or **Identified** if it didn't. A merged pull request behaves differently: it moves the issue to **Fix Applied**, which sticks for as long as the issue stays open. - -When an issue has more than one resolving pull request, progress reflects whether _any_ of them is still open. Closing one while another remains open leaves the issue at **Fix Proposed**. Only when the last open pull request closes without merging does progress fall back. - -### Searching by Progress - -Progress is available as the `issue.progress` search property on the **Issues** page, so you can build [issue views](/product/issues/issue-views/) around it. You can also sort the issue stream by progress. +Autofix steps move the issue along, but only up to a point. Recording a root cause moves an issue to `Diagnosed`; writing a plan and generating code changes don't advance it further on their own. It's the resolving pull request that moves the issue to `Fix Proposed`. -``` -is:unresolved issue.progress:fix_proposed -``` +If that pull request is closed without merging, progress falls back — usually to `Diagnosed`, since Autofix recorded a root cause on the way there, or to `Assigned` or `Identified` if it didn't. A merged pull request behaves differently: it moves the issue to `Fix Applied`, which sticks for as long as the issue stays open. -``` -is:unresolved issue.progress:[diagnosed,fix_proposed] assigned_or_suggested:me -``` +When an issue has more than one resolving pull request, progress reflects whether _any_ of them is still open. Closing one while another remains open leaves the issue at `Fix Proposed`. Only when the last open pull request closes without merging does progress fall back. From ef9fdc3f810599750129d350d94a4c2df878675e Mon Sep 17 00:00:00 2001 From: Nick Meisenheimer Date: Wed, 26 Aug 2026 12:14:47 -0400 Subject: [PATCH 3/4] docs(issues): refine Inbox progress descriptions and copy Frames progress as a derived description rather than a mutable state, confines Identified to a single explanatory paragraph, and redefines Assigned to cover issues suggested for you or your teams. Also fixes comma splices and typos, and replaces em dashes with colons in the preview pane list. Co-Authored-By: Claude Opus 5 (1M context) --- docs/product/issues/inbox/index.mdx | 33 +++++++++++++++-------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/docs/product/issues/inbox/index.mdx b/docs/product/issues/inbox/index.mdx index 6047ff2c7bcd36..ebbf0b2e48140b 100644 --- a/docs/product/issues/inbox/index.mdx +++ b/docs/product/issues/inbox/index.mdx @@ -14,31 +14,32 @@ Inbox is newly available to organizations with [Seer](/product/ai-in-sentry/seer The **Inbox** view is where you manage issues you're responsible for. The Inbox sorts your open issues based on their progress toward a fix and shows you actionable next steps for driving the issues forward. -You can find the Inbox by navigating to **Issues > Inbox**. The number next to the link in the inner nav shows you the count of unresolved issues that are in an `Assigned`, `Diagnosed`, or `Fix Proposed` state where you are the assignee or suggested assignee. +You can find the Inbox by navigating to **Issues > Inbox**. The number next to the link in the inner nav shows you the count of unresolved issues that are `Assigned`, `Diagnosed`, or `Fix Proposed` where you are the assignee or suggested assignee. ## What the Inbox Shows -The Inbox is a two-pane layout (similar to the User Feedback view). The left side shows a list of issues relevant to you, or your teams; the right side includes a preview of the selected issue with relevant details about Seer autofix, linked PRs, as well as relevant activity and comments. +The Inbox is a two-pane layout (similar to the User Feedback view). The left side shows a list of issues relevant to you, or your teams; the right side includes a preview of the selected issue with relevant details about Seer Autofix and linked PRs, as well as activity and comments. The list only includes `unresolved` issues in the categories Seer can work on: error, mobile, frontend, database query, HTTP client, and configuration. Resolved and archived issues never appear, and neither do categories outside that list, such as uptime outages and cron failures. ### Issue Progress -Issues are grouped by their progress state into collapsible sections, sorted so that the mostly recently progressed issues closest to being fixed are at the top of the list. +An issue's progress is derived from the history of activity on an issue. Issues are grouped by their progress into collapsible sections, sorted so that the most recently progressed issues closest to being fixed are at the top of the list. -Progress is a ladder, and the highest applicable state is applied to the issue. An issue move through all five states in order (`Identified` → `Assigned` → `Diagnosed` → `Fix Proposed` → `Fix Applied`), but skipping states is expected and allowed. +Progress descriptions are like a ladder, and the highest applicable description is applied to the issue. | Section | Condition | | ---------------- | -------------------------------------------------------------------------------------- | | `Fix Proposed` | At least one open pull request references the issue (for example, `Fixes SENTRY-123`). | | `Diagnosed` | Seer identified a root cause. | -| `Assigned` | The issue has an assignee. | -| `Identified` | Open issues that no one has picked up. | +| `Assigned` | The issue is assigned to, or suggested for, you or your teams. | | `Fix Applied` | A resolving pull request has been merged, but the issue isn't resolved yet. | -Each section header shows a corresponding progress marker and a count of matching issues. Click a section's header to expand or collapse the section, each section loads 10 issues at a time, you can use **Show more** at the bottom of a section to load additional issues. +Every issue starts with the progress description `Identified`. If an issue is `Identified`, nothing has happened to it yet, so it has no assignee, root cause, or pull request. `Identified` issues are not surfaced in the Inbox. -An issue moves between these sections on its own as work happens. See [How Progress Changes](#how-progress-changes) for the full set of events that advance or roll back an issue's progress. +Each section header shows a corresponding progress marker and a count of matching issues. Click a section's header to expand or collapse it. Each section loads 10 issues at a time; use **Show more** at the bottom of a section to load additional issues. + +An issue moves between these sections as work happens to progress the issue toward a fix. See [How Progress Changes](#how-progress-changes) for the full set of events that advance or roll back an issue's progress. ### Filters @@ -56,11 +57,11 @@ The preview pane is limited to only the details of an issue required to decide w The preview includes: -- **Actions** — Seer actions such as **Find Root Cause**, **Make a Plan**, **Write a Code Fix**, **Create PR**, and **Continue in Seer**, which reflect where Autofix has gotten to on this issue. If Seer isn't available for the issue, you get the standard issue actions (resolve, archive, and so on) instead. -- **Priority and assignee** — Change the issue's [priority](/product/issues/issue-priority/) or reassign it in place. -- **Linked pull requests** — Any pull requests that reference the issue. -- **Autofix summary** — Seer's root cause, plan, and proposed code changes, when they exist. -- **Activity** — The issue's activity feed, where you can leave a comment and tag teammates with `@` or teams with `#`. +- **Actions**: Seer actions such as **Find Root Cause**, **Make a Plan**, **Write a Code Fix**, **Create PR**, and **Continue in Seer**, which reflect where Autofix has gotten to on this issue. If Seer isn't available for the issue, you get the standard issue actions (resolve, archive, and so on) instead. +- **Priority and assignee**: Change the issue's [priority](/product/issues/issue-priority/) or reassign it in place. +- **Linked pull requests**: Any pull requests that reference the issue. +- **Autofix summary**: Seer's root cause, plan, and proposed code changes, when they exist. +- **Activity**: The issue's activity feed, where you can leave a comment and tag teammates with `@` or teams with `#`. ## How Progress Changes @@ -75,7 +76,7 @@ Progress is recalculated as things happen to the issue: | The last open pull request is closed or unlinked | Falls back to `Diagnosed`, `Assigned`, or `Identified`. | | A resolving pull request is merged | Advances to `Fix Applied`. | | Anything else, while the issue is open and already `Fix Applied` | Stays `Fix Applied`. | -| The issue is resolved or archived | The issue closes and no longer has a progress state. | +| The issue is resolved or archived | The issue closes and progress is no longer derived. | | A closed issue is unresolved, regresses, or escalates | The issue reopens and its progress is recalculated. | A few behaviors are worth calling out: @@ -85,12 +86,12 @@ A few behaviors are worth calling out: - A regression clears the root cause before recalculating progress. - An open resolving pull request survives closing the issue and can restore `Fix Proposed` when the issue reopens. -For example, an issue that gets a resolving pull request, has it merged, and then gets resolved in a commit reaches `Fix Proposed`, then `Fix Applied`, then closes with no progress state. If it later regresses, it reopens at `Identified`, because the regression cleared the root cause and no higher condition still applies. +For example, an issue that gets a resolving pull request, has it merged, and then gets resolved in a commit reaches `Fix Proposed`, then `Fix Applied`, then closes. If it later regresses, it reopens at `Identified`, because the regression cleared the root cause and no higher condition still applies. ### Autofix and Progress Autofix steps move the issue along, but only up to a point. Recording a root cause moves an issue to `Diagnosed`; writing a plan and generating code changes don't advance it further on their own. It's the resolving pull request that moves the issue to `Fix Proposed`. -If that pull request is closed without merging, progress falls back — usually to `Diagnosed`, since Autofix recorded a root cause on the way there, or to `Assigned` or `Identified` if it didn't. A merged pull request behaves differently: it moves the issue to `Fix Applied`, which sticks for as long as the issue stays open. +If that pull request is closed without merging, progress falls back, usually to `Diagnosed`, since Autofix recorded a root cause on the way there, or to `Assigned` or `Identified` if it didn't. A merged pull request behaves differently: it moves the issue to `Fix Applied`, which sticks for as long as the issue stays open. When an issue has more than one resolving pull request, progress reflects whether _any_ of them is still open. Closing one while another remains open leaves the issue at `Fix Proposed`. Only when the last open pull request closes without merging does progress fall back. From 0d76c071f140f164f74926af684ff0fe8c4569f2 Mon Sep 17 00:00:00 2001 From: Shannon Anahata Date: Wed, 26 Aug 2026 13:14:06 -0700 Subject: [PATCH 4/4] Updated text for clarity and tone. --- docs/product/issues/inbox/index.mdx | 46 ++++++++++++++--------------- 1 file changed, 22 insertions(+), 24 deletions(-) diff --git a/docs/product/issues/inbox/index.mdx b/docs/product/issues/inbox/index.mdx index ebbf0b2e48140b..da99e334fe2e7c 100644 --- a/docs/product/issues/inbox/index.mdx +++ b/docs/product/issues/inbox/index.mdx @@ -1,32 +1,32 @@ --- -title: Inbox +title: Issues Inbox sidebar_order: 8 description: >- - Learn how to use the Inbox to work through the issues that are closest to - being fixed. + Learn how to use Sentry's Inbox to work through issues that are closest to being fixed, and are assigned to you or your teams. +beta: true --- -Inbox is newly available to organizations with [Seer](/product/ai-in-sentry/seer/) enabled and may change. +Inbox is in beta, and currently available to organizations with [Seer](/product/ai-in-sentry/seer/) enabled. Beta features are still a work in progress and may change. -The **Inbox** view is where you manage issues you're responsible for. The Inbox sorts your open issues based on their progress toward a fix and shows you actionable next steps for driving the issues forward. +The **Inbox** view is where you manage issues you're responsible for, where [Seer](/product/ai-in-sentry/seer/) can help you work on them. The Inbox sorts your open issues based on their progress toward a fix, and shows you actionable next steps for driving the issues toward resolution. -You can find the Inbox by navigating to **Issues > Inbox**. The number next to the link in the inner nav shows you the count of unresolved issues that are `Assigned`, `Diagnosed`, or `Fix Proposed` where you are the assignee or suggested assignee. +Find the Inbox by navigating to [Issues > Inbox](https://sentry.io/orgredirect/organizations/:orgslug/issues/inbox/). Before clicking into the Inbox page, you'll see a number next to **Inbox** in the navigation menu that shows you the count of unresolved issues that are `Assigned`, `Diagnosed`, or `Fix Proposed` where you are the assignee or suggested assignee. ## What the Inbox Shows -The Inbox is a two-pane layout (similar to the User Feedback view). The left side shows a list of issues relevant to you, or your teams; the right side includes a preview of the selected issue with relevant details about Seer Autofix and linked PRs, as well as activity and comments. +The Inbox page is a two-pane layout. The left side shows a list of issues relevant to you, or your teams. The right side has a preview of the selected issue, with relevant details about Seer Autofix status and linked PRs, plus Issue activity and comments. The list only includes `unresolved` issues in the categories Seer can work on: error, mobile, frontend, database query, HTTP client, and configuration. Resolved and archived issues never appear, and neither do categories outside that list, such as uptime outages and cron failures. ### Issue Progress -An issue's progress is derived from the history of activity on an issue. Issues are grouped by their progress into collapsible sections, sorted so that the most recently progressed issues closest to being fixed are at the top of the list. +An issues's progress is determined by the activity on the issue. Issues are grouped into sections based on their progress - `Fix Proposed`, `Diagnosed`, `Assigned`, and `Fix Applied`. -Progress descriptions are like a ladder, and the highest applicable description is applied to the issue. +An issue will be grouped into only one section at a time. The sections are in order from closest to being fixed, to simply assigned. If an issue has no assignee, root cause, or pull request, it will not show up in the Inbox. | Section | Condition | | ---------------- | -------------------------------------------------------------------------------------- | @@ -35,29 +35,27 @@ Progress descriptions are like a ladder, and the highest applicable description | `Assigned` | The issue is assigned to, or suggested for, you or your teams. | | `Fix Applied` | A resolving pull request has been merged, but the issue isn't resolved yet. | -Every issue starts with the progress description `Identified`. If an issue is `Identified`, nothing has happened to it yet, so it has no assignee, root cause, or pull request. `Identified` issues are not surfaced in the Inbox. +Each section header shows a count of matching issues. Click a section's header to expand or collapse it. Each section loads 10 issues at a time; use **Show 10 more** at the bottom of a section to load additional issues. -Each section header shows a corresponding progress marker and a count of matching issues. Click a section's header to expand or collapse it. Each section loads 10 issues at a time; use **Show more** at the bottom of a section to load additional issues. - -An issue moves between these sections as work happens to progress the issue toward a fix. See [How Progress Changes](#how-progress-changes) for the full set of events that advance or roll back an issue's progress. +An issue automatically moves between these sections as work happens to progress the issue toward a fix. See [How Progress Changes](#how-progress-changes) for the full set of events that advance or roll back an issue's progress. ### Filters The toggle at the top of the list controls which issues are shown in the list: - **Me**: Issues assigned to you, or suggested for you. -- **My Teams**: Issues assigned to or suggested for any team you're on. +- **My Teams**: Issues assigned to, or suggested for, any team you're on. - **All**: Every assigned issue in the organization. Learn more about automated assignment by checking out [ownership rules](/product/issues/ownership-rules/) and [suspect commits](/product/issues/suspect-commits/). ### The Preview Pane -The preview pane is limited to only the details of an issue required to decide what to do next without leaving the page. Opening an issue in the preview marks it as seen. Click the open icon next to the title to go to the full [Issue Details](/product/issues/issue-details/) page. +The preview pane shows only the details of an issue that help you decide what to do next without leaving the page. Opening an issue in the preview marks it as seen. Click **Open Issue** to go to the full [Issue Details](/product/issues/issue-details/) page. -The preview includes: +The preview pane includes: -- **Actions**: Seer actions such as **Find Root Cause**, **Make a Plan**, **Write a Code Fix**, **Create PR**, and **Continue in Seer**, which reflect where Autofix has gotten to on this issue. If Seer isn't available for the issue, you get the standard issue actions (resolve, archive, and so on) instead. +- **Actions**: Seer actions such as *Find Root Cause*, *Make a Plan*, *Write a Code Fix*, *Create PR*, and *Continue in Seer*, which reflect where Autofix has gotten to on this issue. - **Priority and assignee**: Change the issue's [priority](/product/issues/issue-priority/) or reassign it in place. - **Linked pull requests**: Any pull requests that reference the issue. - **Autofix summary**: Seer's root cause, plan, and proposed code changes, when they exist. @@ -70,13 +68,13 @@ Progress is recalculated as things happen to the issue: | What happens | Effect on progress | | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | The issue is assigned | Advances to at least `Assigned`. | -| The issue is unassigned | Falls back to `Identified`, unless a root cause or pull request keeps it higher. | +| The issue is unassigned | Not in the Inbox, unless a root cause or pull request puts it in another section. | | Seer identifies a root cause | Advances to at least `Diagnosed`. | | A resolving pull request is opened or reopened | Advances to `Fix Proposed`. | -| The last open pull request is closed or unlinked | Falls back to `Diagnosed`, `Assigned`, or `Identified`. | +| The last open pull request is closed or unlinked | Falls back to `Diagnosed`, `Assigned`, or leaves Inbox if unassigned and no other section applies. | | A resolving pull request is merged | Advances to `Fix Applied`. | | Anything else, while the issue is open and already `Fix Applied` | Stays `Fix Applied`. | -| The issue is resolved or archived | The issue closes and progress is no longer derived. | +| The issue is resolved or archived | The issue closes and no longer appears in the Inbox. | | A closed issue is unresolved, regresses, or escalates | The issue reopens and its progress is recalculated. | A few behaviors are worth calling out: @@ -84,14 +82,14 @@ A few behaviors are worth calling out: - Assignment survives closing and reopening an issue. - Manually reopening an issue preserves the root cause Seer identified. - A regression clears the root cause before recalculating progress. -- An open resolving pull request survives closing the issue and can restore `Fix Proposed` when the issue reopens. +- An open resolving pull request persists through closing the issue, and can show in `Fix Proposed` when the issue reopens. -For example, an issue that gets a resolving pull request, has it merged, and then gets resolved in a commit reaches `Fix Proposed`, then `Fix Applied`, then closes. If it later regresses, it reopens at `Identified`, because the regression cleared the root cause and no higher condition still applies. +For example, an unassigned issue that gets a resolving pull request, the PR merges, and then the issue is resolved in a commit moves through `Fix Proposed`, then `Fix Applied`, then closes. If it later regresses, it reopens, but will not appear in the Inbox because the regression cleared the root cause and no other section conditions still apply. ### Autofix and Progress Autofix steps move the issue along, but only up to a point. Recording a root cause moves an issue to `Diagnosed`; writing a plan and generating code changes don't advance it further on their own. It's the resolving pull request that moves the issue to `Fix Proposed`. -If that pull request is closed without merging, progress falls back, usually to `Diagnosed`, since Autofix recorded a root cause on the way there, or to `Assigned` or `Identified` if it didn't. A merged pull request behaves differently: it moves the issue to `Fix Applied`, which sticks for as long as the issue stays open. +If that pull request is closed without merging, progress falls back, usually to `Diagnosed`, since Autofix recorded a root cause on the way there, or to `Assigned` or leaving the Inbox if it didn't. A merged pull request behaves differently: it moves the issue to `Fix Applied`, which sticks for as long as the issue stays open. -When an issue has more than one resolving pull request, progress reflects whether _any_ of them is still open. Closing one while another remains open leaves the issue at `Fix Proposed`. Only when the last open pull request closes without merging does progress fall back. +When an issue has more than one resolving pull request, progress reflects whether _any_ of them is still open. Closing one while another remains open leaves the issue at `Fix Proposed`. Or if one PR is merged, and another is still open, the issue will move to `Fix Applied`. Only when the last open pull request closes without merging does progress fall back.