What this prompt does
This prompt builds a first-15-minutes incident response playbook with exact actions and commands, not philosophy. It casts the assistant as a senior incident commander and takes four context variables: [severity], [system], [platform], and [comms_channel]. The deliverables walk minute zero to minute fifteen: confirm impact with the exact dashboards to open and what "bad" looks like on each, declare the incident and assign roles (commander, comms, scribe), start a timeline doc and what to record, contain the blast radius via feature flag, traffic shift, or rollback with the commands, a ready-to-send stakeholder comms template, and the decision rule for updating the customer-facing status page.
The structure works because the first fifteen minutes decide whether an incident stays small or becomes a public mess, and under pressure people freeze or skip steps. Assigning an incident commander before anyone touches the system is the key move — debugging without someone owning coordination is how incidents sprawl. Tying every containment option to actual commands, and giving a comms template upfront, removes the hesitation that costs the most early minutes.
When to use it
- Standing up an incident process for a production system before you need it
- When incidents currently sprawl because nobody owns coordination
- When responders skip comms or status-page updates under pressure
- When you want a consistent minute-zero-to-fifteen sequence across the team
- When a recent incident exposed gaps in your early response
- When onboarding engineers into an on-call rotation that handles customer-facing systems
Example output
You get a numbered playbook covering minute 0 to minute 15 with commands inline: which dashboards to open and what bad looks like, how to declare and assign roles, what the scribe records in the timeline, the containment options (feature flag, traffic shift, rollback) with their commands, a stakeholder comms template you can send as-is, and a clear decision rule for the status page. It reads as an ordered sequence of actions, not a discussion of incident theory. The sequence front-loads coordination — declare, assign, start the timeline — before anyone touches the system, because that ordering is what keeps a small incident from sprawling while people improvise. The comms template and status-page rule remove two decisions that otherwise stall the response.
Pro tips
- Set
[severity]accurately, since a SEV-1 customer-facing outage warrants different comms and status-page rules than a minor degradation - Name
[system]and[platform]precisely so the containment commands target the right services - Fill the comms template's placeholders with real audiences before an incident, not during one
- Assign the incident commander first in practice, exactly as the playbook orders it; coordination ownership prevents sprawl
- Treat the status-page decision rule as a starting policy and align it with whatever your organization already promises customers
- Dry-run the playbook in a game day so the role assignments and commands are muscle memory
