Alerts & Incidents

Alerts are findings that want attention now. Incidents group related alerts into one piece of coordinated work with a priority and an SLA. The page has three tabs: Alerts, Incidents, and Analytics.

One design decision shapes everything on the Alerts tab, and it is the first thing to understand:

You cannot resolve an alert by hand. That is deliberate

There is no Resolve action anywhere in the product. Resolution is system-owned: an alert clears only when a scan verifies the underlying condition is genuinely gone, and the resolved banner links to the exact scan job that confirmed it.

The reason is that a hand-resolved alert is an unverified claim. If a human could close a finding, “resolved” would mean “someone said so”, and your alert list would stop being evidence. To clear an alert you fix the resource and re-scan; the Rescan action on an investigating alert does exactly that. If you instead want to stop hearing about something you are not going to fix, that is Suppress, which is an honest statement of a different thing.

Alert statuses

Status	Meaning	Who sets it
Active	Open, nobody has picked it up	System
Investigating	Someone is working it	You
Contained	The finding still exists, but a control now limits it	System
Suppressed	Hidden from active views on purpose	You
Resolved	A scan verified the condition is gone	System only
Dismissed	Closed because the underlying resource no longer exists	System

Contained is still live work. It is easy to read as “handled”, but it means the finding persists and something is merely limiting the damage. That is why Contained offers the same actions as Active: investigate, suppress, assign.

What each action does

Action	Available on	Effect
Investigate	Active, Contained	Marks it as being worked
Suppress	Active, Contained	Hides it from active views. Captures an optional reason
Rescan	Investigating	Re-scans the datastore, or re-runs IAM discovery for an identity alert, so the system can clear it. Row-only, never bulk
Back to Active	Investigating	Puts it back in the queue
Unsuppress	Suppressed	Returns it to active views
Assign / Unassign	Active, Investigating, Contained	Ownership, to a user or a team

Actions are identical from the row menu, a bulk selection, and the drawer footer, because all three read from one definition. A bulk action only offers what every selected alert supports, so a mixed selection correctly offers less.

Suppressed, dismissed, and resolved alerts freeze their mutating actions: no assignment, no incident linkage, no remediation. They are not live work.

Three things about Suppress that are easy to miss

Suppress is the most consequential action on the page and it behaves more carefully than “hide” suggests.

A suppressed alert keeps being evaluated. It is hidden from your views, but every scan still updates it. Suppress is not a mute on the detection, only on your attention.

A suppressed alert can also be Resolved at the same time. If a later scan finds the condition cleared, the alert stays suppressed but picks up a green Resolved tag, and the drawer explains both states. The suppression is your decision and the system does not override it, but you are still told the truth about the underlying condition. If the condition comes back, a suppressed-then-resolved alert stays suppressed rather than reappearing, which is the opposite of how a plain resolved alert behaves: that one reactivates automatically on recurrence.

Some suppressions cannot be lifted from here. When you hide a datastore or an identity, its alerts are suppressed as a consequence. Those carry a Hidden tag and offer no Unsuppress action, because the suppression is not really about the alert. The menu tells you the actual fix: unhide the resource. See Datastores and Identity & Access.

The alerts table

Five counters above it: Total Alerts, Critical Alerts, Active Alerts, Contained, and Resolved.

Column	Notes
Alert	Title, description, and the count of affected objects
Severity	Critical, High, Medium, Low
Status	With secondary tags for Resolved, Hidden, and Not Found where they apply
Category	Data Exposure, Access Control, Encryption, Compliance, Configuration, Data Leak, Data Residency, Toxic Combination, Verification
Source	The datastore or identity it came from
Assignee
Risk	The source’s risk score
Detected	When, plus when it was suppressed, dismissed, or resolved, and by whom

A Not Found tag on a still-open alert means the underlying resource has disappeared but the alert has not been dismissed yet, because the grace window has not elapsed. It is a signal to wait rather than to act.

Two categories are worth knowing by name. Toxic Combination is not one bad setting but a combination that is dangerous together, which is why it can appear when no single finding looks critical. Verification means Argus could not check something, and it is the category behind the banner on the Compliance page: the fix is an IAM permission, not the data. See IAM permissions.

The alert detail drawer

Summary carries the finding and its severity. Source links to the originating datastore or identity. Assignment holds ownership. Evidence is the substance: affected file paths and the sensitive data types involved, so you can judge the finding rather than take it on trust.

Verification Blocked appears when the alert exists because Argus could not verify something, and it names what to grant.

Compliance Impact, Recommendations, Incident, and Policy Violations connect the alert outward: the same condition may fail a control, suggest a fix, belong to an incident, and break one of your own policies. They are four views of one problem, and the drawer links all four rather than making you correlate by hand.

For a resolved alert, the change history shows the scan that verified the clear rather than a “last confirmed” entry, because a resolved finding was not confirmed, it was cleared.

Incidents

An incident groups related alerts into one investigation with a priority, an owner, and a clock. Create one from an alert, add an alert to an existing one, or let the system open one.

Priorities run P1 (Critical) to P4 (Low). Statuses are New, Triage, Ongoing, and Resolved.

Where an incident came from matters, and the table shows it: Manual means a person opened it, while Auto (correlation) and Escalated (from an alert) mean the system did. The two system sources share a colour so you can separate human-opened from machine-opened at a glance, which is the difference between “someone is already on this” and “nobody has looked yet”.

Categories: Data Breach, Access Violation, Compliance Gap, Unauthorized Access, Data Exposure, Config Drift, Policy Violation, Other.

SLA

Incidents carry two separate SLA clocks, and both are tracked independently:

• a response SLA, for how quickly the incident is picked up, and
• a resolution SLA, for how quickly it is closed.

Each reports On Track, Met, At Risk, or Breached. An incident can be comfortably inside its resolution SLA while having already breached its response SLA, which is precisely the failure worth catching: nobody looked at it in time. Thresholds are configured per tenant.

The stat strip shows Active, P1, SLA breached, At risk, MTTR (mean time to resolve), and Resolved today. Active, P1, breached, and at-risk are clickable and filter the table; MTTR and Resolved are read-only.

Analytics

The tuning view, for asking whether your alerting is healthy rather than what is broken right now.

Four KPIs: Resolved This Period, Avg Resolution Time, Noise Ratio, and Critical Open. Then charts for alerts over time, severity distribution, alerts by category, a resolution time trend, and the top affected datastores.

Noise Ratio is the most useful number on this page

It is the share of closed alerts that were suppressed rather than resolved: suppressed over suppressed plus resolved. A high ratio means most of what Argus tells you is being dismissed rather than fixed, which is a signal about your rules, not your team. The fix is usually tightening a policy, adjusting scope, or hiding a known-good datastore, so the alerts stop being generated instead of being suppressed one at a time.

Watch it as a trend. A rising noise ratio is the earliest measurable sign that people are starting to ignore the alerts tab.

Read Avg Resolution Time alongside it. Because resolution is system-owned, this measures the real round trip from detection to a scan verifying the fix, not how quickly someone clicked a button.

A workflow that works

1. Filter to Active and Critical, and work down.
2. Investigate what you are taking on, and Assign it so two people do not duplicate work.
3. Fix the resource, then Rescan from the alert. Let the system resolve it.
4. Suppress with a reason only what you have genuinely accepted, and expect it to keep being evaluated.
5. Group anything that is really one event into an Incident so the SLA and the timeline apply once rather than per alert.
6. Check Noise Ratio on Analytics every few weeks. If it is climbing, fix rules rather than alerts.