Incident Hub

The Incident Hub (/incidents/:id) is the full-detail view for a single incident. Everything about an incident lives here: the current stage, agent analysis, HITL approval controls, execution logs, timeline, and collaboration tools.

​

Page layout

The top of the page shows:

• Incident title and severity badge
• Current stage indicator — a stage stepper with all six stages, the active one highlighted. On desktop this is a vertical rail down the left side of the page (collapsible to a slim icon strip); on narrower/mobile layouts it becomes a horizontal row of pills instead.
• Control chip — shows who’s driving right now: “Control: You’re in control” or “Control: AI driving”, with a button to take control or release it back to the agent. This live control state is separate from your org’s autonomy setting (see below) — the chip only ever shows these two control states, and it’s this live state (not the autonomy setting) that also gates the stage-control band described below.
• Confidence dials — two of them: an Overall confidence dial (the minimum confidence across completed stages, annotated with which stage is driving that number) and a Root cause confidence dial (diagnosis’s own score), shown when it differs from the overall figure.
• Action cluster — SAGE, Promote to problem, Catch Me Up, Escalate, and the HITL approval button all live together in a cluster at the top right (see below).

Below the header, desktop layout is a fixed-width left stages rail plus a center content panel that takes the rest of the width. A right-hand panel only appears when you click into a specific data source the agent queried — there’s no persistent right sidebar. The incident timeline sits directly below the incident title, with the Agent Activity Feed below that, in the same column as the main content — not off to the side.

​

The action cluster

At the top right of the page:

• SAGE — opens an incident-scoped chat drawer to ask SAGE questions about this specific incident. SAGE has full context: the current stage, diagnosis, execution logs, and all data sources the agent queried. See Chat with ECHO for the distinction between ECHO and SAGE.
• Promote to problem — manually promote this incident to a problem record if you identify a recurring root cause.
• Catch Me Up — a quick AI-generated summary popover if you’re jumping into an incident that’s already in progress.
• Escalate — currently disabled with a “coming soon” tooltip; escalation workflows aren’t wired up yet.

​

Stage-specific sections

The main content area changes depending on which stage the incident is currently in. Each stage surfaces the information relevant to that moment in the lifecycle, though some sections carry forward across stages when they’re still relevant (noted below).

​

Detection stage

When the incident first opens, the Detection section shows:

• Triggering Alerts — the raw alerts that caused the incident to open, with metric values, threshold details, and timestamps
• Affected services identified from the alert payload
• Time since first detection

Triggering Alerts isn’t detection-only — it keeps showing on the current stage’s view for as long as any of the underlying alerts are still firing, even after the incident has advanced past detection.

​

Triage stage

The triage view shows the Impact Assessment box:

• Error Rate
• Latency
• Saturation
• Blast Radius
• Users Affected
• Business Impact

The agent uses this data to assign severity and determine whether to escalate immediately or continue with standard triage. Like Triggering Alerts, Impact Assessment carries forward on the current-stage view as long as it’s the best-available grounded assessment, not just during triage.

​

Diagnosis stage

The diagnosis view shows the agent’s root-cause analysis and proposed next steps:

• Recommendations — a list of proposed fixes, each with a title, description, risk level, and tracker ticket link when available. All recommendations show here regardless of status (pending, approved, rejected, executed, or mooted) — nothing is hidden once it’s actioned. If the agent re-diagnoses after new data comes in, older rounds render as collapsed, disabled groups above the current one, oldest first — the newest, actionable round is always at the bottom, so you can still see history without it crowding out what’s actionable now.
• Data sources — the telemetry signals the agent queried (logs, metrics, traces, runbooks). Click any data source badge to expand the raw query and response.
• Confidence reasoning — the agent’s explanation of what it found and how confident it is.
• Seen before — previously solved problems with matching root-cause patterns (see Seen before card below).
• Runbook citations — runbook content the agent read during diagnosis, with links to the source.

​

Resolution stage

Once a recommendation is approved (or auto-executed under an autonomous-execution setting), the incident advances to resolution. The resolution view shows:

• Execution logs — timestamped entries for each action the agent ran, with command details and status
• Progress — how many of the approved fixes have been applied vs. the total
• Any partial failures or escalations, if a fix could not be fully executed

The execution log is honest: if the agent could not execute a fix, you will see an explicit “escalated to human review” entry rather than a false success. An Actions Performed panel also appears from the resolution stage onward (through verification and closure) once there are executed actions to show — this is where actioned recommendations end up, separate from the recommendations list itself.

​

Verification stage

After fixes are applied, the incident moves to verification. This stage doesn’t have a special metric-comparison table of its own — it shows the same AI Analysis summary and stage-progress rows every other stage does, describing what the agent checked and what it found. The incident advances to closure only when the agent confirms sustained recovery.

​

Closure stage

Closure doesn’t have a distinct summary section of its own — it shows the same generic AI Analysis card and stage-progress rows every other stage does, describing what happened, what was done, and how long it took.

​

The HITL approval panel

When the agent is waiting for your approval, a Review Approval button appears in the header’s action cluster. Clicking it opens a dialog with the full request:

• The proposed action and its scope
• The agent’s risk assessment (low / medium / high)
• Approve and Reject buttons
• A Dive deeper button — opens a short form, and its confirm button (“Send back to diagnosis”) sends the incident back to the diagnosis stage so the agent runs a fresh root-cause pass before acting

​

Stage controls when you’re in control

The stage-control band is gated on the live control chip above, not on your org’s autonomy setting. It only appears once someone has actually taken control of the incident (the chip reads “Control: You’re in control”) — a Supervised-mode org sees no control band until a person takes control, and a Self-driving org sees the exact same band as soon as someone does. It’s also only visible while the incident is still open — the entire band disappears once the incident is resolved or reaches closure, so there’s no control band left to interact with at that point. When it appears, it renders below the header for the incident’s active stage and is your primary way to drive the incident forward by hand:

• Approve & Continue — accept the current stage’s findings and move to the next stage
• Re-run Stage — have the agent redo the current stage’s analysis
• Mark Complete — close out the current stage
• Rollback and skip controls for stepping backward or jumping ahead in the stage sequence

​

The incident timeline

Below the incident title, the timeline shows every event in the incident’s history in chronological order — agent actions, stage transitions, human interventions, approval decisions, and Slack posts. Each entry has a timestamp and actor label (agent name or user email). The Agent Activity Feed sits in the same column, just below the timeline.

​

Collaboration Bar

At the bottom of the page, the Collaboration Bar is a call/war-room strip — it shows your comms-channel link (e.g. the incident’s Slack war-room), whether a call is active, and (during an active call) mute, focus, and end-call controls plus a transcription/participants panel. SAGE and Promote to problem are not here — they live in the action cluster at the top of the page (see above).

​

Focus mode

Focus mode is call-specific: it’s only available from the Collaboration Bar while a call is active, and it expands the call/transcription view rather than the whole page.

​

Seen before card

If sureops has solved incidents with a matching root-cause pattern before, a Seen before card appears alongside the diagnosis content, with an “N match(es)” badge in its header. Each match row shows a link to the matched problem’s external ID, a percentage match-score badge, a recurrence-chain-depth badge (×N) when the match itself has recurred, the problem title, a short “why it matched” reasoning line, and an Open runbook link.

​

Navigating back

The back arrow at the top of the page uses smart navigation — if you arrived from the Incidents list it returns you there, and if you arrived from the Command Center it returns you to the dashboard.