Statuses & lifecycles
This is the canonical reference for every state in Argus. If you are looking at a badge and want to know what it means and what will move it, it is here.
Four patterns that repeat everywhere
Section titled “Four patterns that repeat everywhere”Argus reuses the same four ideas across every object. Learn them once and most statuses explain themselves.
1. System-set states cannot be set by hand. Some states are conclusions, not decisions: Resolved, Contained, Dismissed. They exist because a scan verified something. No button sets them, because a state that a person can assert is not evidence. Where you want to say “I accept this”, that is a different, explicitly human action: Suppress for alerts, Waive for violations.
2. Deleted resources are dismissed, not deleted. When discovery stops finding something, it is marked Not Found and a 24-hour grace window starts, protecting against a transient blip. After the window, its open alerts and violations are dismissed and it drops out of compliance, risk, and reporting totals. If it reappears, everything reactivates. Nothing is destroyed, so history survives and a deleted resource can never be used to quietly launder a bad score.
3. Hidden is a posture decision, not a filter. Hiding a datastore or identity excludes it from metrics and suppresses its alerts. It always requires a reason and is always audited.
4. Terminal states cannot be transitioned out of. They are the end of a lifecycle. Anything further is a new record.
Severity
Section titled “Severity”The same four-level scale is used for alerts, policy violations, compliance controls, and audit events.
| Severity | Meaning |
|---|---|
| Critical | Act now |
| High | Act this cycle |
| Medium | Real but contained |
| Low | Track it |
Risk bands are a separate five-level scale, because a risk score is a computed measure rather than a judgement: Critical, High, Medium, Low, Minimal. See Risk engine.
Incidents use their own priority scale: P1 (critical), P2 (high), P3 (medium), P4 (low).
Datastores
Section titled “Datastores”| Status | Meaning | Set by |
|---|---|---|
| Discovered | Found in the account, not yet scanned | System |
| Needs Credentials | A database engine awaiting connection details | System |
| Scanning | A scan is in progress | System |
| Ready | Scanned; classification and risk are current | System |
| Error | The last scan failed. The reason is in the detail drawer | System |
| Not Found | Absent from the latest discovery run | System |
| Hidden | Manually excluded from active views and metrics | You |
Not Found dominates Hidden. A datastore that was hidden and then deleted reads Not Found, because the more important fact is that it is gone. Hidden is driven by a separate flag rather than the status itself, which is why the two can coexist underneath and why precedence has to be defined.
Only a discovery run can clear Not Found. A failed scan against a deleted store just re-confirms it is gone. Full detail in Discovery & scanning and Datastores.
Alerts
Section titled “Alerts”| Status | Meaning | Set by |
|---|---|---|
| Active | Open, unclaimed | System |
| Investigating | Someone is working it | You |
| Contained | The finding persists, but a verified compensating control limits it | System only |
| Suppressed | Hidden from active views on purpose | You |
| Resolved | A scan verified the condition is gone | System only |
| Dismissed | The underlying resource no longer exists | System only |
Three behaviours that are easy to miss:
- Contained reverts to Active automatically when the compensating control is no longer observed. It is a live state that tracks reality, not a parking space.
- Resolved reactivates automatically if the condition is rediscovered.
- A suppressed alert keeps being evaluated, and can hold Suppressed and Resolved at once. In that combination it stays suppressed even on recurrence, unlike a plain resolved alert.
There is no user Resolve action anywhere. See Alerts & Incidents.
Alert categories: Data Exposure, Access Control, Encryption, Compliance, Configuration, Data Leak, Data Residency, Toxic Combination, Verification.
Incidents
Section titled “Incidents”| Status | Meaning |
|---|---|
| New | Opened, not yet triaged |
| Triage | Being assessed |
| Ongoing | Active response |
| Resolved | Terminal. Archives and locks the incident |
Permitted transitions are explicit:
| From | To |
|---|---|
| New | Triage, Resolved |
| Triage | Ongoing, Resolved |
| Ongoing | Resolved |
Resolved is the single terminal state, and resolving captures alert handling, root cause, summary, and lessons learned in one action.
SLA states, tracked separately for response and resolution: On Track, Met, At Risk, Breached.
Incident sources: Manual (a person opened it), Auto (correlation), Escalated (from an alert).
Policies
Section titled “Policies”| Status | Meaning |
|---|---|
| Draft | Not evaluated |
| Simulating | Evaluated, but violations are tracked without notifications or remediation |
| Active | Evaluated, and it creates real violations |
| Disabled | Turned off |
Policy violations
Section titled “Policy violations”| Status | Meaning | Actions available |
|---|---|---|
| Open | Detected, unclaimed | Take Over, Waive, Resolve, Assign |
| In Progress | A person owns it | Waive, Resolve, Assign |
| Waived | Accepted and muted, with an optional expiry | Lift Waiver only |
| Resolved | Cleared | None. Terminal |
| Dismissed | The datastore is gone | None. Terminal, system-set |
Resolve is not a mute. If the condition persists, the next scan reopens the violation. Waive is the accept-and-mute action. Lift Waiver is deliberately the only action on a waived violation, so a bulk action across a mixed selection can never silently un-waive an accepted risk. See Policies.
Recommendations
Section titled “Recommendations”Fully system-controlled. There is no user transition path at all.
| Status | Meaning |
|---|---|
| Open | Live, unaddressed |
| Reopened | Was closed, and the condition returned |
| Pending | A fix is dispatched and waiting on human approval. Derived, never stored |
| Remediating | A fix is in flight. Derived, never stored |
| Mitigated | A compensating control is verified, but the finding persists |
| Resolved | Verified gone |
| Dismissed | The subject no longer exists |
Precedence, top wins:
- Subject not found → Dismissed
- A scan re-detects the finding → Reopened
- A scan confirms it is gone → Resolved
- Verification confirms a compensating control while the finding persists → Mitigated
- An execution is in flight → Remediating or Pending
Mitigated is not closed, and its fix stays runnable. It promotes to Resolved when a later scan shows the finding fully gone. Risk acceptance is not a recommendation status: it lives on the alert or violation that surfaced it. See Recommendations.
Remediation workflows
Section titled “Remediation workflows”| Status | Meaning |
|---|---|
| Draft | Not runnable |
| Enabled | The only status that can run |
| Disabled | Turned off |
Run modes: Manual, Semi-auto, Auto (admin only, executes without approval). Triggers: Manual, Alert, Policy violation, Scheduled, Recommendation. Classes, derived from the steps and never set by hand: Remediation (fixes root cause), Mitigation (compensating control), Mixed.
Remediation executions
Section titled “Remediation executions”| Status | Meaning | Terminal |
|---|---|---|
| Pending approval | Waiting on a human | No |
| Approved | Cleared, awaiting claim | No |
| Awaiting agent | An auto run fired but no agent is available. Re-dispatched automatically | No |
| Running | In progress | No |
| Verifying | The action succeeded, confirmation pending | No |
| Completed | Done and verified | Yes |
| Failed | Did not complete | Yes |
| Cancelled | An operational “do not start” on an approved run | Yes |
| Rejected | A reviewer’s explicit “no” on a pending approval | Yes |
| Rolled back | Reversed | Yes |
| Rollback failed | The reversal did not complete cleanly | Yes |
Four distinctions that matter operationally:
- Verifying is not Completed, and must not read as green. Verification is part of every workflow, so a run is not finished until the verify job returns.
- Awaiting agent is not Failed. The remediation never failed; there was simply no operational agent to dispatch to. Only auto runs land here, because manual and semi-auto surface an offline agent to the human at trigger or approval time instead.
- Rejected is not Cancelled. Rejected is a reviewer declining; Cancelled is an operational stop on something already approved.
- Rollback failed is not Failed. The original action ran far enough to leave changes that could not be cleanly reverted. Check the target’s actual state by hand; it is the one status that requires manual investigation.
Rollback is available for 24 hours after a successful live run. A successful dry run can be promoted to live for 24 hours, after which cloud state may have drifted and the option expires. See Remediation.
Agents
Section titled “Agents”| Status | Meaning |
|---|---|
| Online | Heartbeating and working |
| Idle | Heartbeating, no work to do. Healthy |
| Stalled | Heartbeating, but the work loop is wedged. Functionally down while reporting online |
| Offline | Enabled but not heartbeating |
| Awaiting | A provisional record; no agent has connected yet |
| Replaced | A tombstone from the conflict-replace flow. Hidden by default |
| Disabled | Deliberately off, or auto-disabled after going stale. Hidden by default |
Online and serving are different questions, and Argus tracks them separately: whether the work loop is alive, and whether the agent is actually draining the queue. An agent that polls but never claims is not serving, which is what Stalled captures. A busy agent at capacity stops polling and is still healthy, so it is not mislabelled.
Version lag badges: Update recommended (behind recommended), Below minimum (behind the minimum supported version).
Type: Bootstrap (self-enrolled with a token) or Manual. Pool: Baseline or Burst. See Agents.
Scan and discovery jobs
Section titled “Scan and discovery jobs”| Status | Meaning |
|---|---|
| Pending | Queued, no agent has claimed it |
| Running | An agent is working it |
| Completed | Finished |
| Failed | Did not finish. A reason is recorded |
| Cancelled | Stopped before completion |
A job abandoned mid-run, or left unclaimed with no healthy agent, is reaped and marked failed with a reason rather than hanging.
Account assessments
Section titled “Account assessments”| Status | Meaning |
|---|---|
| Pending | Queued |
| In Progress | Running |
| Completed | Finished |
| Failed | Did not complete |
The optional identity track runs and completes independently of the datastore scan, with its own Pending, Completed, and Failed, which is why an assessment can finish while identity results are still landing.
Compliance controls
Section titled “Compliance controls”| Status | Meaning |
|---|---|
| Compliant | Verified as meeting the control |
| Non-compliant | Verified as failing |
| Partial | Some in-scope resources pass, some fail |
| Not Verified | Could not be checked, almost always a missing IAM read permission |
| Not applicable | Out of scope for your estate |
Not Verified is neither a pass nor a fail. It is a blind spot that drags your score down for a fixable reason. See IAM permissions and Compliance.
Cloud accounts
Section titled “Cloud accounts”Two independent signals, deliberately not merged into one badge because they fail differently:
| Signal | Meaning |
|---|---|
| Connected / Disconnected | Whether Argus has proven cloud access to the account |
| Agent online / No agent | Whether any agent in the tenant is currently alive |
See Cloud Accounts.
Identities
Section titled “Identities”Lifecycle: Active, Hidden, Not Found. Not Found dominates Hidden, as with datastores.
Flags are separate from lifecycle and describe what the scan found: Admin Access, Over-Provisioned, Stale, No MFA, External, Sensitive Data. A hidden identity stops being re-scored until unhidden, which is stronger than hiding a datastore. See Identity & Access.
| Status | Meaning |
|---|---|
| Pending | Invited, not yet accepted |
| Active | In use |
| Inactive | Disabled. Holds no permissions, whatever roles remain attached |
See Users & Roles.