Issues

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, that is a signal definition — 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.

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.

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

Severity is also how you keep a noisy project quiet: a delivery rule can carry a Match by severity condition so it routes only issues at or above medium, high, or critical. Scope your rules that way rather than routing every severity everywhere. See Route notifications.

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

The same actions are available from a Slack or Microsoft Teams issue card (inline Resolve, Ignore, Mute, Re-open buttons) and from the CLI:

sazabi issues list --status open
sazabi issues resolve <issue-id>
sazabi issues ignore <issue-id>
sazabi issues reopen <issue-id>

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 to silence a specific issue's notifications.

Suppression happens on its own. When the agent detects a problem that already has an open issue, it does not open a second one — the recurrence is folded into the existing open issue instead of creating a duplicate. This applies only while the issue is open: if a problem you already resolved or ignored happens again, Sazabi opens a new issue for the new occurrence (see Lifecycle).

Muting silences an issue you choose without closing it. A muted issue stays open and visible, but its recurrences do not notify your team again. Mute is independent of status — an issue can be muted in any state.

While an issue is muted, Sazabi tracks a mute hit count — how many times the problem re-fired since you muted it, shown on the issue as "Suppressed while muted." A rising count tells you a muted condition is getting worse. Unmuting resumes notifications and resets the count.

sazabi issues mute <issue-id>
sazabi issues unmute <issue-id>

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