> ## Documentation Index > Fetch the complete documentation index at: https://docs.sazabi.com/llms.txt > Use this file to discover all available pages before exploring further. # Issue lifecycle and severity > The states an issue moves through, what the four severity levels mean, and how to resolve, ignore, re-open or reject an issue. Every [issue](https://docs.sazabi.com/detect/issues.md) has a status and a severity. The status says where the issue is in its life, and the severity says how urgent it is. Both decide what reaches your team and when. ## Lifecycle An issue is always in one of three states. * **Open**: the agent detected the problem and it needs attention. Open issues appear in the inbox and can trigger notifications. * **Resolved**: the problem was addressed. Resolved issues leave the active inbox but stay searchable. * **Ignored**: the issue did not need a fix (a false positive or known noise). Ignored issues also leave the active inbox and stay searchable. Resolved and ignored are not terminal: you can **re-open** either one back to open. You cannot move directly between resolved and ignored. Re-open first, then resolve or ignore again. [Rejection](https://docs.sazabi.com/manage/billing.md#issue-rejection) is permanent. A rejected issue disappears from your issue views and cannot be re-opened. ### When a problem comes back What happens depends on the issue's status when the problem recurs. * **Open or ignored:** Sazabi folds the recurrence into the existing issue instead of opening a second one. * **Resolved in the last 30 days:** the agent re-opens that issue with a note on what came back. A re-open is not billed as a new issue. * **Resolved longer ago:** Sazabi opens a new issue for the new occurrence. A recurrence the agent does not recognize as the same problem can still open a new issue. ### Quiet issues resolve themselves Sazabi resolves an open issue on its own after 30 days with no new occurrences. The exception is an issue linked to a Linear, Jira, or GitHub Issues task that syncs status: its task decides when it closes. ## Severity Every issue has one of four severities, from least to most urgent: **low**, **medium**, **high**, **critical**. The agent assigns a severity when it opens the issue, and medium is the default. | Severity | What it means | | - | - | | **Critical** | Happening now in production: an outage of the service, of a flow most users depend on, or of a whole feature; or data loss, a security exposure, or failed payments. | | **High** | Happening now in production: at least 1% of attempts failing or a region down; or production data loss, exposure, or failed payments that has stopped. | | **Medium** | A failure limited to a few users or one path, a broad internal failure, a production outage that ended on its own, or serious harm outside production. | | **Low** | No user or system impact, a transient blip, an internal failure on one item or a rare path, or other work outside production, including eval, training, and canary runs. | If the agent got a severity wrong, change it from the CLI. The change appears in the issue's history. Raising severity on an open, unmuted issue can send an **Issue updated** notification through your delivery rules; lowering it notifies no one. ```bash theme={"system"} npx -y @sazabi/cli@latest issues update --severity high --note "Checkout errors reach 3% of requests" ``` ### Use severity to keep a project quiet Severity decides which issues reach which channels through delivery rules. A rule's **Match by severity** condition routes only the severities you select, such as **high** and **critical**. Selecting **high** alone does not include **critical**. Scope your rules that way rather than routing every severity everywhere. See [Route notifications](https://docs.sazabi.com/triage/notifications.md). ## Respond to an issue From the issue inbox you can: * **Resolve** an open issue to mark the problem addressed. * **Ignore** an open issue that does not need a fix. * **Re-open** a resolved or ignored issue. * **Reject** an eligible issue to dispute it, remove it from your issue views, and exclude it from billable issue usage. See [Billing](https://docs.sazabi.com/manage/billing.md#issue-rejection) for eligibility, reasons, and how to reject an issue. **Resolve**, **Ignore**, **Mute**, and **Re-open** are also available from a Slack or Microsoft Teams issue card and from the CLI. A re-open can carry a note of up to 2000 characters that is posted with the re-open announcement and shown in the issue's history. ```bash theme={"system"} npx -y @sazabi/cli@latest issues list --status open npx -y @sazabi/cli@latest issues resolve npx -y @sazabi/cli@latest issues ignore npx -y @sazabi/cli@latest issues reopen --note "POST /checkout returns 502 again" npx -y @sazabi/cli@latest issues reject --reason not_real ``` `--reason` takes `not_real`, `duplicate`, `incorrect_details` or `something_else`. See [`sazabi issues`](https://docs.sazabi.com/reference/cli/issues) for every option. Muting quiets an issue without changing its status. See [Muting and suppression](https://docs.sazabi.com/detect/issues.md#muting-and-suppression). Use **resolve** when the problem is fixed, **ignore** when it never needed a fix, and **mute** when you know about it and cannot fix it yet. ## Further reading > [card] [Service status](https://docs.sazabi.com/triage/status.md) > > How an open issue moves a component's status. > [card] [Troubleshooting notifications](https://docs.sazabi.com/triage/troubleshooting.md) > > When an issue opened and nobody was notified. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.