Skip to main content
HITL (Human-in-the-Loop) gates are the specific moments when sureops stops and waits for a human decision before proceeding. Every approval gate creates a durable record: who approved what, when, and from which stage.

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_hitl off (default) or autonomous_execution risk 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_hitl on — 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 when auto_approve_hitl is off.
If you want high-risk actions to always gate no matter what, don’t enable 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:
  1. Command Center → Pending Approvals panel — a list of all open approval requests across all active incidents.
  2. Incident detail page → Recommendations section — inline approve/reject controls with full context.
Each approval card shows:
  • 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)

Email

sureops can send an email notification to members with the 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 the approvals:grant capability, which is granted to:
  • Commander
  • Admin
  • Owner
Responders and Observers cannot approve HITL gates. See Roles & Permissions for the full capability matrix.

Timeout behavior

Approval gates have a configurable timeout. When a gate goes unanswered, sureops acts according to the hitl_timeout_action setting for your environment.
The escalate default means an unanswered approval never silently proceeds. The incident enters a waiting-for-human state, visible on the Command Center dashboard and via Slack, plus email for anyone who has opted into escalation emails (off by default, per-user). auto_decide carries the same guarantee — it never silently executes an action either, it just auto-rejects instead of leaving the recommendation pending.
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 is escalate:
  1. The incident moves to a waiting for human state
  2. The graph is suspended — no further agent actions run
  3. The pending approval remains visible on the dashboard
  4. Any team member with Commander role or above can claim the incident and resume
To claim a system-escalated incident: open the incident, click Take Control. This adopts the suspended state — you become the controlling user, the auto-release timer starts, and you can act on the pending approval or navigate the incident manually. After taking control and resolving the approval (approve or reject), release control to let the AI resume, or continue in Supervised mode. If the underlying system recovers on its own while an approval is still pending, sureops doesn’t leave a stale approval waiting for a decision that no longer matters — the recommendation is automatically marked mooted (a distinct terminal state, not silently rejected or dropped) and the incident routes to closure as recovered. If a pending approval disappears from your list without you acting on it, this is why.

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 reinvestigate recommendation 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_fix proceeds to resolution; reinvestigate returns to diagnosis; monitor moves to a watch-and-wait closure; escalate suspends to human takeover.