Write a blameless incident report from the material below. Focus on system conditions, decisions, and evidence rather than individual fault. Do not speculate beyond the record or include secrets, customer personal data, access tokens, or internal credentials. Inputs: [INCIDENT SUMMARY AND IMPACT] [TIMELINE AND EVIDENCE] [SYSTEMS AND DETECTION] [RESPONSE ACTIONS AND OWNERS] [ROOT CAUSE OR CURRENT HYPOTHESES] [FOLLOW-UP WORK AND AUDIENCE] Ask up to 3 clarifying questions only if a required input is missing, timestamps lack a time zone, impact duration cannot be determined, or ownership is unclear. Do not invent outage start times, customer counts, alerts, root causes, remediation completion, or communications.
Produce a 900- to 1,300-word report in this format: 1. Executive summary: incident date, service, user impact, duration, current status, and audience-safe language. 2. Impact: affected users or functions, failed user journeys, geographic or account scope, data integrity, security, financial, and contractual effects. Mark unknown fields. 3. Timeline: a chronological table with timestamp and time zone, observed event, action, evidence source, and owner. Separate facts from later interpretations. 4. Detection and response: how the incident was found, alert performance, escalation path, mitigation actions, and when service recovered. 5. Contributing conditions and root cause: state confirmed causes separately from hypotheses. Include technical and process conditions, but do not assign personal blame. 6. What went well and what did not: concrete operational observations. 7. Follow-up actions: table with action, intended risk reduction, accountable owner, due date, dependency, and verification method. Do not mark work complete without supplied evidence. 8. Communication record and remaining risks. Before answering, check that the timeline does not claim recovery before the listed mitigation, and that every action item has an owner or is clearly marked unassigned.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [INCIDENT SUMMARY AND IMPACT] | Describe the incident, service affected, known user impact, start and end times, and current status. | Checkout API returned 502 errors from 09:07 to 09:41 EDT on September 23; about 31% of card-payment attempts failed; service is recovered and no duplicate charges are known. |
| [TIMELINE AND EVIDENCE] | Provide timestamped events, logs, alerts, deploys, tickets, and observations with time zones and sources. | 09:05 EDT deploy checkout-api 4.18.0; 09:07 error-rate alert fired; 09:12 on-call confirmed failures; 09:27 rollback started; 09:41 error rate returned to baseline; Grafana dashboard and incident channel logs available. |
| [SYSTEMS AND DETECTION] | List affected systems, dependencies, monitoring, alerts, and how the issue was detected. | Checkout API, Redis session cluster, payment gateway; PagerDuty alert on 5xx rate detected the issue; no alert existed for Redis connection-pool saturation. |
| [RESPONSE ACTIONS AND OWNERS] | List containment, mitigation, recovery actions, their timestamps, and responsible roles or people. | Nina acknowledged alert at 09:08; Omar disabled new checkout deployment at 09:25; Lee rolled back at 09:27; Priya verified successful payments at 09:43. |
| [ROOT CAUSE OR CURRENT HYPOTHESES] | State confirmed causes, contributing conditions, and unresolved hypotheses with supporting evidence. | Confirmed: 4.18.0 introduced a Redis client configuration incompatible with the existing pool limit. Hypothesis: pre-production load test did not model checkout-session concurrency. |
| [FOLLOW-UP WORK AND AUDIENCE] | List proposed action items, owners, due dates, dependencies, and whether the report is internal or customer-facing. | Internal report. Nina to add saturation alert by Oct 1; Omar to add concurrency load test by Oct 8; Lee to require Redis config compatibility check in release checklist. |
How to use
- Collect timestamps from alerting, deployment, and incident records before drafting; choose one time zone and preserve it throughout.
- State impact in user journeys and scope, not only in system metrics, and mark estimates as estimates.
- Confirm action owners and due dates with the responsible people before treating the follow-up table as a commitment.
- Follow up with: “Turn the follow-up actions into a weekly status template with evidence required to close each item.”
Variations
Customer incident update
Use this when customers need a concise, factual update without internal implementation detail.
Write a customer-facing incident update based on [KNOWN IMPACT], [START AND END TIMES], [CURRENT STATUS], [MITIGATION], and [NEXT UPDATE PLAN]. Use plain language and state time zone. Explain the affected service and user-facing effect, what has been restored, and any safe action customers should take. Do not name internal systems, speculate on cause, promise prevention, or claim data was unaffected unless confirmed. Output a subject line, 120- to 180-word update, and a short status-page version.
Security incident record
Use this when documenting a suspected or confirmed security event for the response team.
Create an internal security incident record from [EVENT DETAILS], [AFFECTED ASSETS], [EVIDENCE], [CONTAINMENT ACTIONS], [ASSESSMENT], and [OWNERS]. Preserve chain-of-custody facts, timestamps with time zone, access scope, affected data categories, and actions taken. Separate indicators, confirmed findings, and hypotheses. Do not include secrets or make legal, notification, or regulatory conclusions. Output an incident summary, timeline, evidence register, containment status, investigation questions, and tracked next actions with owners.
Incident review agenda
Use this when preparing a meeting to review an incident and assign prevention work.
Create a 45-minute incident-review agenda using [INCIDENT SUMMARY], [TIMELINE], [OPEN QUESTIONS], and [PROPOSED ACTIONS]. Include purpose, attendees by role, a factual timeline review, impact and detection discussion, contributing-conditions discussion, action-item decision points, and closing commitments. Assign time boxes totaling 45 minutes. State which questions require evidence before the meeting and do not characterize unproven causes as facts. Output a facilitator script and a decision log template.
Tips
- Build the timeline from independent records such as alerts, deploy events, and logs before reading chat commentary, which often mixes observation with interpretation.
- A recovery time should mean the affected user journey was verified, not merely that a rollback command was issued.
- Follow-up items need a verification method, such as an alert test or load-test result; “improve monitoring” is not a closeable action.
- Keep technical root cause separate from contributing conditions such as missing tests, unclear ownership, or incomplete runbooks.
FAQ
When should we write the incident report?
Start a factual draft during or soon after containment, then finalize root-cause and action sections after evidence is reviewed.
Do incident reports need to name individuals?
Use owners for actions and timeline entries when useful, but describe failures as system and process conditions rather than personal blame.
What if root cause is still unknown?
Say that it is unknown, list supported hypotheses, and assign investigation work with a decision point for updating the report.