When does sureops pause?
sureops pauses for approval at the following trigger points:Post-diagnosis: recommendation approval
After the Diagnosis Specialist produces root cause analysis and proposes remediation actions, the agent pauses before any fix is attempted — unless your org has opted into autonomous execution for that incident (off by default; see Supervised vs Self-Driving). This is the primary gate in the incident pipeline. The approval request includes:- The proposed root cause(s) with confidence scores
- Each recommended action with its risk classification
- The executor for each action (runtime execution vs. fix PR vs. human)
- Supporting evidence (metric data, log excerpts, trace analysis)
P1 / P2 severity incidents
Critical and high-severity incidents have additional approval requirements, even in Self-Driving mode. The agent cannot auto-execute anything for a P1 or P2 incident regardless of your Auto-execute low / medium-risk fixes (autonomous_execution) settings.
High-risk or destructive actions
There are exactly two hard carve-outs that always require explicit human approval, regardless of mode or auto-approve settings, and neither can be turned off: P1/P2 severity incidents (above), and any recommendation that opens a fix PR (below). Outside of those two, an action’s risk level does not by itself force a pause — it depends on which auto-approve knob your org has configured:auto_approve_hitloff (default) orautonomous_executionrisk ceiling — a recommendation classified as high risk (rollbacks that affect production traffic, scaling operations above a defined threshold, configuration changes to security-sensitive surfaces, or anything the diagnosis agent marks as potentially irreversible) gates on human approval, because it exceeds the configured risk ceiling.auto_approve_hitlon — this setting auto-approves every pending recommendation regardless of its risk classification, with no risk check at all. The only things that still force a pause are the two hard carve-outs above. These two auto-approve settings are mutually exclusive:autonomous_execution’s risk-ceiling logic only runs whenauto_approve_hitlis off.
auto_approve_hitl — use autonomous_execution with a max_auto_risk ceiling instead (see Supervised vs Self-Driving).
Fix-PR recommendations always gate
Any recommendation that opens a fix PR against your GitOps repository always pauses for human review — even if your org has auto-approve or autonomous execution turned on. A fix PR mutates your source repository on merge, so you always see the draft diff before it can be approved. This is a hard-coded safety carve-out, not a configurable option.What an approval request looks like
In-app
Pending approvals appear in two places:- Command Center → Pending Approvals panel — a list of all open approval requests across all active incidents.
- Incident detail page → Recommendations section — inline approve/reject controls with full context.
- The incident name and severity
- The stage the request originated from
- Proposed actions with risk labels
- The AI’s reasoning summary
- A confidence score
Slack notification
If you have Slack connected, sureops posts an approval request to your configured incident notification channel. The message includes:- Incident name and link
- The proposed action summary
- Approve and Reject buttons (requires the sureops Slack app)
approvals:grant capability (Commander, Admin, Owner) when an approval request is created — this is independent of Slack, not a fallback triggered by a Slack timeout. Email notifications for approval requests are opt-in and disabled by default: each user enables them individually in their notification preferences. If you’re relying on email as a safety net for missed Slack approvals, confirm the relevant users have opted in — otherwise no email will be sent.
Who can approve?
Approvals require theapprovals:grant capability, which is granted to:
- Commander
- Admin
- Owner
Timeout behavior
Approval gates have a configurable timeout. When a gate goes unanswered, sureops acts according to thehitl_timeout_action setting for your environment.
The gate timeout duration is configured in Settings → General, in the “Approval Timeout” card (“Timeout (minutes)” field). The
hitl_timeout_action behavior itself (escalate / extend / auto_decide) is not exposed in the UI today — it’s set via the environment’s settings JSONB / API only.
HITL gates by mode
Both Self-Driving and Supervised modes have gates, but the set differs.Self-Driving mode
Gates fire at the specific triggers listed above: post-diagnosis recommendation approval, P1/P2 severity, and fix-PR recommendations always gate; whether a high-risk action also gates depends on which auto-approve setting your org has configured (see “High-risk or destructive actions” above). Auto-approve settings can reduce the number of gates for lower-risk actions on P3/P4 incidents. See Supervised vs Self-Driving for configuration details.Supervised mode
In Supervised mode, detection and triage still run automatically with no gate — the difference from Self-Driving is the post-diagnosis gate: every batch of recommendations pauses for your explicit approval before resolution runs, with no auto-approve bypass available. The same action-specific gates (P1/P2 and fix-PR recommendations always) also apply. Supervised mode does not, by itself, stop the incident after every stage — that’s a separate axis. If you want the incident to pause after every stage so you can inspect it before it advances, take direct control of the incident (Take Control, available in either mode) rather than relying on the mode setting — see Supervised vs Self-Driving.What happens if no one approves
When a gate times out and the action isescalate:
- The incident moves to a waiting for human state
- The graph is suspended — no further agent actions run
- The pending approval remains visible on the dashboard
- Any team member with Commander role or above can claim the incident and resume
Mixed approval batches
When the Diagnosis Specialist proposes multiple recommendations, you can approve some and reject others. A few rules apply:- You cannot approve both an execute-fix recommendation and a reinvestigate recommendation in the same batch. These have opposite meanings (act vs. dig deeper), so the system forces you to choose one direction.
- Approving a
reinvestigaterecommendation sends the agent back to the Diagnosis stage with focus on what you flagged. The maximum number of re-investigation rounds is configurable (default: 2) to prevent infinite loops. - Each approved recommendation’s intent determines the routing:
execute_fixproceeds to resolution;reinvestigatereturns to diagnosis;monitormoves to a watch-and-wait closure;escalatesuspends to human takeover.