What this prompt does
This prompt writes a post-incident report for an incident on [incident_date] affecting [affected_systems] in a [system_type] environment, lasting [duration] with [impact_scope]. It produces the full structured document — executive summary, timeline, root cause, impact, resolution, action items, and lessons learned — so the review focuses on systemic fixes rather than blame.
The structure works because it separates audiences and drills to root cause. The executive summary is written in three to four sentences for [stakeholder_audience] without technical background. The timeline logs entries every [timeline_granularity] in UTC, from first alert to resolution. Root cause uses a 5-Whys analysis that distinguishes the trigger from the underlying vulnerability, so the fix addresses why it was possible at all. Impact is quantified including [user_count], failed requests, and SLA effects. Resolution links the temporary workaround and permanent fix, action items get owners and priorities in a table, and lessons learned cover what went well and what needs to change.
When to use it
- You need a post-incident report after an outage in a
[system_type]environment. - You want a 5-Whys analysis that targets the systemic cause, not just the symptom.
- You need an executive summary readable by
[stakeholder_audience]. - You want a precise UTC timeline at
[timeline_granularity]intervals. - You need action items with clear owners, priorities, and due dates.
- You want lessons learned that drive concrete process changes.
Example output
Expect a complete report assembled section by section. It leads with a three-to-four-sentence executive summary written for [stakeholder_audience] without technical background, covering what happened, the business impact, the root cause, and current status. A UTC timeline then logs entries every [timeline_granularity] from first alert through detection, escalation, fix deployment, and verification. A 5-Whys root-cause analysis separates the immediate trigger from the underlying vulnerability, and a quantified impact section covers [user_count], failed requests, and SLA violations. The resolution section links the temporary workaround, the permanent fix, and the relevant pull requests, an action-items table assigns owner, priority, due date, and status to each item, and a lessons-learned section captures what went well and what needs to improve.
Pro tips
- Keep the executive summary genuinely non-technical so
[stakeholder_audience]can grasp impact and status without a glossary. - Use the 5-Whys honestly to reach the systemic vulnerability; stopping at the trigger produces a fix that won't prevent recurrence.
- Log the timeline in UTC at
[timeline_granularity]so cross-region responders read it without converting time zones. - Assign every action item a real owner and due date; an unowned item in the table is one that never gets done.
- Quantify impact with real numbers where you have them —
[user_count], failed requests, SLA breaches — and mark estimates as estimates. - Capture what went well alongside what failed, since reinforcing good detection and response is as valuable as fixing the gaps.
