The six stages
1
Detection
What it is: The moment sureops receives an alert.What sureops does: Ingests the alert, deduplicates against any open incidents, and opens a new incident record. The incident commander agent runs an initial context read — pulling relevant alerts, service metadata, and dependency context from your landscape — to prepare for triage.What you see: A new incident appears in the Command Center with its triggering alerts listed.
2
Triage
What it is: Rapid severity assessment and impact scoping before deep investigation begins.What sureops does: Assigns a P1–P4 severity based on alert priority and business impact signals — customer-facing impact, revenue impact, data-loss risk, and how broadly the degradation reaches across your services. Identifies which services and dependencies are in scope.What you see: Severity badge, affected service list, and estimated user impact. On-call schedule–aware routing is on our roadmap but not yet available; the incident isn’t auto-assigned an owner at this stage.
3
Diagnosis
What it is: Root cause analysis — the deepest and most tool-intensive stage.What sureops does: The diagnosis specialist agent runs a ReAct investigation loop, pulling metrics, logs, traces, and Kubernetes state through your connected integrations. It correlates signals across services, follows the dependency graph to identify blast radius, and produces a set of ranked recommendations with confidence scores and supporting evidence.What you see: A structured root cause analysis, per-recommendation confidence, and (if applicable) proposed change tickets. This is where the control-mode approval gate lives: in Supervised mode, the recommendations always pause here for your approval before any action proceeds.
4
Resolution
What it is: Executing the fix.What sureops does: The resolution specialist executes the recommendations approved at the diagnosis gate above. Depending on the recommendation type, this may mean restarting a deployment, scaling a resource, rolling back to a previous image via ArgoCD, or opening a draft fix PR against your repository. Two carve-outs always require explicit human approval before this stage runs, regardless of mode or auto-approve settings: P1/P2 severity incidents, and any recommendation that opens a fix PR. See Control modes for how auto-approve and the risk ceiling work together.What you see: A real-time execution log with each action’s status (applied / failed / skipped). If a fix PR is opened, a link appears directly in the incident timeline.
5
Verification
What it is: Confirming the fix actually worked before declaring the incident resolved.What sureops does: Re-queries the same metrics and service health checks that fired the original alert. Validates that they are back within baseline thresholds. If recovery isn’t confirmed, sureops routes back to diagnosis for one bounded re-investigation with the verification findings as context; if that retry also fails to confirm recovery, it escalates to a human rather than retrying indefinitely. It never marks an incident resolved when it can’t verify.What you see: The same AI Analysis card you see at every other stage — an agent badge (“Analyzed by Verification Specialist”), a confidence dial, a “Why this confidence?” reasoning panel, and the agent’s stage summary stating whether recovery was confirmed. If verification fails, the incident stays open and you are notified.
6
Closure
What it is: Wrapping up the incident with a durable record.What sureops does: Every closure gets an AI-authored stage summary — what triggered the incident, the root cause, what fixed it, and how long it took — unconditionally, preserved in the timeline alongside all agent findings and any human overrides. Separately, depending on your org’s incident policy for this severity (Settings → Incident Policy) and whether an open Problem Record already covers this pattern, sureops may open a new Problem Record for longer-lived tracking. The executive-ready root cause analysis (RCA) document and the knowledge-base embedding that improves future diagnosis are both properties of that Problem Record, not of the incident itself — they’re only generated when a Problem Record is actually created. An incident whose policy doesn’t create one (or whose pattern already has an open Problem Record covering it) gets its stage summary, but no RCA document and nothing added to the knowledge base.What you see: A completed incident with its AI stage summary always present, and — only when a Problem Record was opened for this severity — a shareable RCA document and a new entry in the Problems view. Links to any opened change tickets or fix PRs appear either way.
Stage flow at a glance
The “Human approval required?” column above is entirely about the control-mode approval gate — whether a recommendation batch needs your sign-off before it executes. It’s a separate thing from the stage-by-stage “pause and wait for Approve & Continue” UI: that only appears once you click Take Control on this specific incident, independent of whether the org is set to Supervised or Self-driving. A Supervised-mode incident doesn’t automatically park between stages by itself — it only does once someone takes control of it; a Self-driving incident, if someone takes control, parks between stages exactly the same way. See Control modes for how the two fit together.
Whether closure opens a Problem Record — a longer-lived investigation object that links related incidents and tracks whether the underlying root cause has been permanently addressed — depends on your org’s incident policy for that severity (Settings → Incident Policy). Recurrence itself never changes whether that policy gate applies — but if an open (not resolved) Problem Record already covers the same pattern, the incident links to that existing record instead of minting a new one, so a repeat of an already-tracked pattern may not add a new row to the Problems view even when the policy would otherwise create one. See Problem records for details.
Next: Control modes — Supervised and Self-driving