Incidents and after-action reports
An alert is one thing going wrong: a failed check, a missed heartbeat, a security detection. An incident is the record you keep while several of those are handled as one event - who is managing it, what is affected, what was said and when, and what you learned afterwards. Alerts page people; incidents tell the story.
Incidents live under Incidents in the left navigation, with two entries: Incidents and AARs. Opening incidents by hand and writing reports works on every plan; the automatic parts below need the SRE agent.
Anatomy of an incident
Section titled “Anatomy of an incident”| Field | Notes |
|---|---|
| ID | Per-workspace, INC000042 style, assigned on creation |
| Subject | Required |
| Description | Free text |
| Severity | P0 - Critical, P1 - High, or P2 - Medium |
| Status | Triggered, Under Investigation, or Resolved |
| Affected servers, services | Picked from your hosts and services |
| Incident manager | Shown on the overview when set |
| Subscribers | People following the incident; the creator is subscribed automatically |
| Linked alerts | Alerts the incident was opened from |
| Public | Whether, and under which title, it shows on your status pages |
Statuses are not a locked ladder: any valid status can be set from any other. Setting Resolved stamps the resolved time and resolver, and that timestamp is what the after-action timings are computed from.
Open an incident
Section titled “Open an incident”Incidents, then Create Incident. The form asks for a subject and
severity, and optionally a description, affected servers, and affected
services. The incident starts as Triggered, you are subscribed to it,
and the timeline gets its first entry: “Incident created”.
Opened automatically by Kicker
Section titled “Opened automatically by Kicker”Under Admin, then LLM Settings, the Kicker - Incident Automation card has an Enabled switch and an Incident severity floor (Critical, High, Medium, or Low). It needs alert auto-triage on and the SRE agent, which is included on Business and the trial. With it on, Kicker opens an incident when its triage of an alert concludes that a person needs to be involved. The rule is deterministic:
- When Kicker acknowledges an alert that meets the severity floor (default: High), an incident is opened for it.
- When Kicker’s verdict is escalate, an incident is opened regardless of severity.
- If a non-resolved incident already exists for that alert, it is reused rather than duplicated.
The incident is titled after the alert and its host, created by
“Kicker (SRE agent)”, and linked to the alert. The alert’s own timeline
gains an Open incident link. Two things close it again without a
human: a later benign verdict resolves a Kicker-opened incident that is
still Triggered (never one a person opened or has moved on), and
resolving the alert closes the incident that was opened from it.
See AI triage and Kicker for the triage loop itself.
Running the incident
Section titled “Running the incident”The incident page has four tabs.
Overview shows the fields above plus two sections. Status page has a switch, “Show on public status page”, a customer-facing title with its own Save Public Title button, and a checkbox per status page so an incident can appear on one page and not another. Close-out summary appears after resolution (see below).
Timeline is where the incident is actually worked. Each entry is a
message, a status change, or a severity change, with who or what wrote
it - a person, Kicker, or the system. The update form at the top takes a
message, a checkbox “Also show this update on the public status page”,
and an optional status change. Changing the status here is how you move
an incident to Under Investigation or Resolved.
Public updates render on the status page under the incident’s public title; private ones stay in the workspace. That split lets you keep the raw investigation (“db-2 is swapping, failing over”) internal while the customer sees “We have identified the cause and are applying a fix”.
Subscribers lists who is following. After Action Report is covered below.
The header has a Delete action. Deleting an incident does not touch the alerts it was linked to.
What happens after resolution
Section titled “What happens after resolution”Within 48 hours of an incident being resolved, Kicker drafts a close-out summary and a one-line root cause from the timeline and linked alerts, and shows them in the Close-out summary section with a provenance line naming the model that wrote them. The summary is a draft for a human to read, not a verdict.
If the incident or its first alert has a Slack thread, Kicker also posts “INC000042 resolved - close-out summary” as a reply broadcast to the channel, with the root cause and a link back, and two buttons: Create draft AAR and No AAR needed. Choosing the second writes a system entry to the timeline recording who declined and from where. Both buttons disappear once an AAR exists. The Slack integration is described in Notification channels.
After-action reports
Section titled “After-action reports”An after-action report (AAR) is the written record of an incident: what happened, why, what worked, what to change. One AAR per incident.
Sections
Section titled “Sections”Whether Kicker drafts it or you start from the template, the report has the same nine sections:
- Summary
- Timeline of Incident
- Five Whys
- Root Cause
- Impact
- What Went Well
- What Could Be Improved
- Action Items
- Lessons Learned
Above the body sit three timings: Time to detect, Time to engage, and Time to mitigate. Kicker fills them from the alert and incident timestamps when it drafts; they are free-text fields you can correct.
Draft, edit, publish
Section titled “Draft, edit, publish”From the incident’s After Action Report tab, Start After Action
Report opens the editor seeded with the template. If the incident is
resolved and the workspace has AI quota left, Kicker’s draft is used
instead of the empty template - the same draft the Slack Create draft
AAR button produces. Drafts are always saved as Draft.
The editor is Markdown with Save Draft, Publish, and Cancel.
A published report shows a Published label in the viewer and can still
be edited. AARs in the navigation lists every report with its ID
(AAR000042), a preview, status, author, and date, searchable by ID,
summary text, or author.
What Kicker learns
Section titled “What Kicker learns”When Kicker drafts a close-out summary it also records a postmortem episode in its memory, so a later triage of a similar alert can cite what happened last time. That memory is visible and editable under Admin, then Agent Memory; see AI triage and Kicker.
Incidents over the API and MCP
Section titled “Incidents over the API and MCP”list_incidents and get_incident are available to AI assistants over
MCP, read-only, with status and severity filters; see the
MCP tool reference. The HTTP API creates
and updates incidents and AARs; see the API reference.
Next steps
Section titled “Next steps”- Working with alerts for the alerts an incident is built from
- Public status pages for how public incidents render
- Services for the affected-services picker