> ## 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. # Issues > An issue is a problem Sazabi found and decided is worth your attention — with a lifecycle, a severity, and a place to respond. An issue is a problem the Sazabi agent found in your data and decided is worth your attention. An issue carries the agent's analysis of what happened and why, moves through a small lifecycle, and gives your team one place to respond. It is more than a threshold breach. Open issues for a project live at **Issues** in the project (the issue inbox). ## How to think about issues ### Issues and alerts are different An issue resembles an alert in one way: it tells you something needs attention. The difference is what arrives. An alert is a signal — a threshold crossed, with the investigation still ahead of you. An issue arrives already investigated: the agent attaches what happened, why, and the evidence, so your team starts from an analysis rather than a graph. ### Issues and monitors are different There is no monitor behind an issue. A monitor is a rule you write in advance — a query, a threshold, a schedule — that catches only the failure modes you predicted and must be kept in sync as your system changes. Sazabi detects issues by investigating your live data, so there is no rule set to author or maintain, and detection keeps up as your system evolves. When you do want an explicit rule for a specific condition, write a scheduled [automation](https://docs.sazabi.com/guides/detect/automations.md) — the deliberate exception, not the default. ## How Sazabi detects issues The agent opens an issue when it detects a problem during an investigation — either one you started or one an automation kicked off. Because issues come from investigation rather than a static rule, each one records what the agent found, not only that a number crossed a line. Sazabi also files an issue for each confirmed vulnerability it finds in your connected repositories. See [Security review](https://docs.sazabi.com/guides/build/security-review.md). Every issue carries a stable **name**, a short **description** of the problem, a **severity**, an optional linked **component**, and a **status**. When the same problem recurs, Sazabi matches it to the existing open issue by its stable name rather than opening a duplicate. ## 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. Re-opening is a manual action; if a problem you already resolved happens again, Sazabi opens a new issue for the new occurrence rather than silently re-opening the old one. [Rejection](https://docs.sazabi.com/guides/administer/billing.md#issue-rejection) is permanent. A rejected issue disappears from your issue views and cannot be re-opened. ## 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; medium is the default. Severity affects which issues reach which channels through delivery rules (see [Route notifications](https://docs.sazabi.com/guides/detect/notifications.md)). Severity is also how you keep a noisy project quiet: a delivery 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/guides/detect/notifications.md). ## Issues and notifications An issue is not the same as being notified about it. An **issue** is the problem itself — a stateful record the agent opens, with a severity and a lifecycle. A **notification** is a message Sazabi sends to a channel to tell your team about an issue event. Opening an issue does not guarantee anyone is notified. Whether an issue reaches you, and where, is decided by your delivery rules — so an issue can sit in the inbox with no notification sent, and one issue event can fan out to several channels. See [Route notifications](https://docs.sazabi.com/guides/detect/notifications.md) for how delivery is configured. ## Components An issue can be linked to a **component** — a service or system element that the status surface tracks. A linked issue drives that component's status: an active issue moves the component from operational to degraded or outage, and resolving the issue returns it to operational. See [Service status](https://docs.sazabi.com/guides/detect/status.md) for how components work. ## Responding to an issue From the issue inbox you can: * **Investigate from the issue** — open the issue's thread and ask the agent follow-up questions with the issue's context already loaded. * **Hand off to your coding agent** — copy the issue's agent prompt into Claude Code, Codex, Cursor, or Devin to fix the problem in your own repository and open a pull request linked to the issue. See [Coding agents](https://docs.sazabi.com/get-started/coding-agents.md#hand-an-issue-to-your-coding-agent). The **Copy prompt** action on issues is in limited release and not yet shown in every organization; `sazabi issues agent-prompt` prints the same prompt for everyone. * **Resolve** — mark the problem addressed. * **Ignore** — mark the issue as not needing a fix. * **Re-open** — bring a resolved or ignored issue back to open. * **Reject** — dispute an eligible issue, remove it from your issue views, and exclude it from billable issue usage. See [Billing](https://docs.sazabi.com/guides/administer/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: ```bash theme={"system"} sazabi issues list --status open sazabi issues resolve sazabi issues ignore sazabi issues reopen sazabi issues agent-prompt ``` ## Muting and suppression Muting and suppression both keep things quieter, but they are different: **suppression** is automatic and keeps duplicate issues from piling up, while **muting** is an action you take on a specific issue. **Suppression** happens on its own. When the agent detects a problem that already has an **open** or **ignored** issue, it does not open a second one: the recurrence is folded into the existing issue instead of creating a duplicate. Only resolved issues are left out: if a problem you already **resolved** happens again, Sazabi opens a new issue for the new occurrence (see [Lifecycle](#lifecycle)). A recurrence the agent does not recognize as the same problem can still open a new issue. **Muting** quiets an issue you choose without closing it. A muted issue keeps its status and stays visible. While it is muted, a new report with the same issue name is counted on the muted issue instead of opening a new one, and the issue sends no [**Issue still open**](https://docs.sazabi.com/reference/notification-types.md) reminders. Muting and unmuting send no notification. You can mute an issue in any status, but a mute holds back reports only while the issue is open or ignored; a muted resolved issue holds back nothing. A muted open issue is still resolved automatically after 30 days with no new occurrences, and from then on its recurrences open new issues. The exception is an issue linked to a Linear, Jira, or GitHub Issues task that syncs status: its task decides when it closes. To keep known noise quiet, **ignore** the issue instead. While an issue is muted, Sazabi tracks a **mute hit count**: how many same-name reports the mute held back, shown on the issue as "Suppressed while muted." A rising count tells you a muted condition is getting worse. Unmuting resumes the reminders and resets the count. ```bash theme={"system"} sazabi issues mute sazabi issues unmute ``` Use **mute** when you know about a problem and cannot fix it yet; use **resolve** when it is fixed; use **ignore** when it never needed a fix. ## History Each issue keeps an event history — **created**, **resolved**, **ignored**, **muted**, **unmuted**, and **updated** — with the timestamp and the actor (the agent or a specific user) for every event. Resolution notes added when an issue is resolved appear in the history, which makes it useful for postmortems. History is preserved after an issue is resolved or ignored. ## Further reading > [card] [Service status](https://docs.sazabi.com/guides/detect/status.md) > > Track component health from your issues. > [card] [Create automations](https://docs.sazabi.com/guides/detect/automations.md) > > Open issues automatically on a schedule or from a signal. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.