Incidents
Intelligence → Incidents (/gravity/incidents, with detail pages at
/gravity/incidents/[id]) is where related alerts land as a single, trackable record instead
of a scattered list of individual firings. It sits under Intelligence in the sidebar rather
than Operations - worth knowing if you’re looking for it by menu location - but it’s the
center of the operational loop described in this section.
How an incident is created
Section titled “How an incident is created”Incidents are created automatically. Sencai correlates related alerts - from monitoring, fleet agents, and cloud-instance errors - into one incident, using a dedup key so the same underlying problem doesn’t produce a new incident every time it fires again. There’s no “New Incident” button in the app: incidents originate from alert correlation, not manual entry.
Each incident tracks:
| Field | Meaning |
|---|---|
| Severity | Critical, High, Medium, or Low |
| Status | Open, Investigating, Resolved, False Positive, or False Positive (Closed) |
| Alert count | How many individual alerts were deduplicated into this incident |
| First seen / Last seen | When the underlying problem first fired and most recently recurred |
Filtering the list
Section titled “Filtering the list”The incident list has three filter chips - All, Open, and Critical - each showing a live count, so you can jump straight to what needs attention without scanning a full history of resolved incidents.
Triaging an incident
Section titled “Triaging an incident”Opening an incident shows its context bundle - a window of audit events and configuration-drift events collected automatically around the time it started - organized into Audit Events and Drift Events tabs. This is usually the fastest way to spot what changed right before things went wrong. It can take a few seconds after creation for the context bundle to populate.
From an open or investigating incident, you can:
- Resolve - mark the underlying problem as fixed.
- Mark as False Positive - mark it as a false alarm rather than a real problem. This is a distinct, permanent classification (not silently converted to a normal resolution later), so the fact that something was a false alarm survives even after it’s closed out and stops affecting deduplication.
Both actions require the Member role or higher in the organization the incident belongs to.
Root-cause candidates
Section titled “Root-cause candidates”Below the context bundle, an incident shows a ranked list of possible root causes - deploys, IAM changes, configuration drift, config changes, or resource exhaustion near the time the incident started - each with a confidence score and a link to the underlying evidence. These are heuristic indicators meant as a starting point for investigation, not a verdict. A link on this section takes you to a deeper, AI-assisted root-cause view; see Root cause analysis for how that works.
If analysis hasn’t finished yet, the incident shows “Analysis in progress” rather than an empty list - give it a moment and reopen the incident.
The dedup key
Section titled “The dedup key”An incident’s detail view shows its dedup key - the value Sencai used to recognize a repeat of the same underlying problem rather than opening a new incident. It’s most useful when you’re trying to understand why two alerts you’d expect to be separate ended up on the same incident, or vice versa.
What’s next
Section titled “What’s next”- Root cause analysis - the deeper, AI-assisted investigation view linked from an incident’s root-cause section
- Runbooks - the actions you trigger to actually fix what an incident found
- Auto-remediation - matching incident patterns to a runbook automatically
- Support: SLA - response-time commitments tied to incident severity