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.How Sazabi detects issues
The agent opens an issue when it detects a problem during an investigation — either one you started or one Sazabi started on its own. 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. 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.Types and categories
Sazabi classifies every issue by type, and optionally by category within a type. When the agent opens an issue it assigns at least one type (an issue can have several), plus any categories that describe the problem more precisely. A category always belongs to one type, so adding a category adds its type. The issue inbox and the issue page show the classification as one badge per type, with the categories in parentheses: Security (Active attack), or Reliability (Outage, Regression). The inbox filter menu narrows the list by type. Types also drive routing. A delivery rule’s Match by type condition and a task creation rule’s Type condition select issues by type, so you can send security issues to a security channel. Categories are labels only; rules do not match on them. See Route notifications. Sazabi has 4 types and 18 categories.Reliability
Users or systems see failures, slowness or lost work.- Outage: A service, a flow most users depend on, or a whole feature is down or failing for most attempts.
- Silent failure: Work fails or stops without an error anyone sees: dropped events, skipped jobs, empty results.
- Regression: Something that worked before a deploy, configuration or dependency change no longer does.
- Performance degradation: Latency, throughput or timeouts got worse enough that users or callers notice.
- Capacity risk: A resource is near its limit: disk, memory, connections, quotas, rate limits or an expiring certificate.
- Background job failure: Scheduled, queued or batch work fails, retries without end or falls behind.
- Dependency failure: A database, cache, queue or third-party API the service relies on fails or slows down.
- Frontend breakage: Pages, screens or client code crash, fail to load or render wrong for users.
Correctness
The system runs but produces wrong results or state.- Data integrity: Data is wrong, duplicated, lost or inconsistent between stores.
- Business flow breakage: A business flow such as signup, checkout, billing or fulfilment completes with the wrong outcome.
- Configuration drift: Configuration, flags or infrastructure differ from what was intended or between environments.
Security
Someone is attacking, abusing or could exploit the system or its data.- Active attack: Attack payloads, exploit attempts or authentication attacks that reach the application, not traffic the firewall blocked entirely.
- Suspicious access: Unusual logins, privilege changes or data egress by an account or credential.
- Exposure: A secret in logs, a vulnerable dependency, risky code or configuration that could be exploited.
- Abuse and fraud: Bots, scraping, fake signups, promotion abuse or payment fraud.
- Agent misbehavior: An AI agent acts outside its instructions: prompt injection, unexpected tool use or a runaway loop.
Efficiency
Waste or blind spots: spend that grew without reason, or telemetry that went missing.- Cost anomaly: Spend or usage on infrastructure, vendors or models rose without a matching rise in work.
- Observability gap: Logs, metrics or traces a team relies on stopped arriving, lost fields or became too noisy to use.
--types sets the full list of types the issue has after the change, and --categories does the same for categories. Removing a type removes its categories, and each category you add brings its type back. The change appears in the issue’s history. To filter by classification from the CLI, use --type and --category on sazabi issues list. See sazabi issues.
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.
- 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. The Copy prompt action on issues is in limited release and not yet shown in every organization;
sazabi issues agent-promptprints the same prompt for everyone. - Resolve, ignore, re-open or reject the issue. See Issue lifecycle and severity.
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. A problem you already resolved is handled differently: the agent re-opens the issue if it came back within 30 days of resolving, and opens a new issue after that. See Issue lifecycle and severity. 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 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. See Issue lifecycle and severity. 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.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
Service status
Track component health from your issues.
Detection catalog
Browse every issue category Sazabi classifies and the signals it detects.