Incident Management

The Incidents screen (sidebar → Incidents, URL /operations/incidents) is where you work the queue of alerts CloudPeek has pulled in and triaged. It follows familiar IT-service- management (ITSM/ITIL) conventions, so each incident has a severity, priority, owner and status.

The incident list

The list groups incidents into tabs so you can focus:

• Triaged (default): incidents that have finished automatic triage and are ready for review.
• Escalated: incidents an analyst marked as needing investigation.
• All Incidents: everything.
• Needs attention: incidents flagged for action.
• My Incidents: incidents assigned to you.
• Clusters: incidents grouped by similarity (useful for spotting a single campaign behind many alerts).

Above the list you can search ("Search incidents…") and filter by status (Triaging, Triage Complete, In Progress, Resolved, Closed) and priority (P1-P4).

Severity and priority

Opening an incident

Click any incident to open its detail view (/operations/incidents/[id]). At the top you'll see the AI Analysis / Triage Summary, the written summary that automatic triage produced. Below it, detail tabs appear based on what triage found:

• Summary: the overview and key details.
• Timeline: the sequence of events.
• Next Steps: the suggested investigation plan (the follow-up actions).
• Blast Radius: for vulnerabilities, what's potentially affected.
• Patching Guide: for vulnerabilities, remediation guidance (CVEs, fixed versions).
• IOCs: the indicators of compromise extracted from the alert.
• Recommendations: suggested actions.

(Tabs only appear when triage produced the relevant data.)

Reviewing the triage outcome

Once you've read the analysis, record your decision with the Review Outcome dropdown:

• Close: "No action needed." The incident is closed.
• Escalate: "Needs investigation." The incident moves to In Progress and into the Escalated tab.
• Reject: "Triage incorrect." This opens a Reject Triage Outcome dialog where you must give a reason. Rejections are valuable feedback on triage quality.

After your decision the incident shows a Closed, Escalated or Rejected badge.

Assigning owners

Use the assignee dropdown (shown as Unassigned until set) → Assign → Select Users to give an incident one or more owners. Assigned incidents appear in each owner's My Incidents tab.

Other actions

• Comments: add notes to an incident for your team (internal comments are supported).
• Timeline / events: every change to an incident is recorded as an activity event.
• Artifacts: files attached to the incident are listed on the incident (see Artifacts).

Automation activity on an incident

Alongside the triage and follow-up work CloudPeek does on every incident, your own automations can contribute to one: a scheduled workflow that gathers evidence, follows one of your playbooks, or proposes a response.

When they do, that activity is visible from the incident itself, so you can see what ran and what it produced without leaving the investigation. Anything an automation wants to change still stops for a person's approval first, exactly as described in Human-in-the-Loop (HITL).

The incident lifecycle

• Pending: created, queued for triage.
• Triaging: automatic triage is running.
• Triage Complete: analysis is done; ready for your review.
• In Progress: being actively worked (e.g. after you escalate).
• Resolved / Closed: finished.
• Cancelled: stopped without resolution.

Where incidents come from

Most incidents are created automatically when CloudPeek polls a connected incident source (see Tools & Integrations). You can also create incidents via the Incidents API, useful for wiring up a tool that isn't a built-in source. Every newly created incident is queued for triage automatically.

Related

• Automatic Triage: how the AI analysis is produced.
• Automations: workflows you define that can contribute to an incident.
• Threat Hunting: patterns across many incidents.
• Incidents API: manage incidents programmatically.