Skip to main content
Every issue 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 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. 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.

​
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.

​
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 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.
--reason takes not_real, duplicate, incorrect_details or something_else. See sazabi issues for every option. Muting quiets an issue without changing its status. See 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

Service status

How an open issue moves a component’s status.

Troubleshooting notifications

When an issue opened and nobody was notified.