step by step
1
stabilize first
If the incident is active, follow the operating runbook and contain harm before writing the narrative. do not let retrospective automation delay recovery.
2
define the incident window
Record the earliest known symptom, latest known good state, affected system or customer, and the timezone. search a slightly wider window to capture precursor events.
3
collect visible events
Search exact errors, app names, terminal windows, ticket IDs, deployment identifiers, and meeting terms. preserve the original source app and time for each event.
4
build three lanes
Put directly observed events in facts, interpretation in inferences, and missing or conflicting state in unknowns. correlation is not a proven cause.
5
verify against authoritative systems
Check service logs, release artifacts, Sentry, billing, CRM, database, or account state as appropriate. state clearly when screenpipe history is the only available source.
6
remove sensitive material
Replace tokens, customer payloads, private messages, and personal data with narrow summaries or secure artifact references.
7
publish the reviewed note
Include impact, timeline, confirmed cause if known, recovery, unresolved risk, owners, and follow-up dates. do not claim resolution without a current system read-back.