Work a live production incident in the right order — triage and stabilize first, then find the cause, then write the summary and postmortem — so the fire is out before the writeup begins.
An incident is not a bug — it's a bug with a clock and an audience. Diving straight into the root cause is the wrong first move when customers are affected: triage and stabilization come first, diagnosis second, the writeup last. Out of order, you get either a hasty fix that makes things worse or a thorough investigation while the outage drags on. This workflow keeps the order honest — contain it, understand it, then communicate it — and leaves you with a postmortem instead of a fading memory.
Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.
Triage and stabilize
First, scope the blast radius and find the fastest safe mitigation — roll back, flag off, fail over — before chasing the underlying cause. Stop the bleeding, then investigate.
Understand the failing path
With the pressure off, get a clear read of the code path that failed, so the diagnosis is grounded in what the system actually does rather than what the dashboards imply.
Write the incident summary
Capture what happened, when, who was affected, and how it was contained — in a structured form stakeholders can read without a war-room replay.
Produce the postmortem
Turn the summary into a durable postmortem and changelog entry — cause, timeline, fix, and the follow-ups that stop a repeat.
The incident is contained, its cause is understood, and you walk away with a stakeholder summary and a written postmortem — instead of a fixed symptom and a story that gets fuzzier each retelling. The proper code fix then runs through the debugging workflow.
This is for a live incident with customers affected right now; debugging is for fixing a bug properly when you have time. Here the first job is triage and communication under pressure, and the output is a contained incident plus a postmortem. The deep, tested code fix afterward is the debugging workflow's job.
Because the details are accurate only right after the incident, and they decay fast. Capturing the summary and postmortem while the timeline is fresh is what turns an outage into something the team actually learns from.
No. It contains and documents the incident. The durable, behavior-tested fix runs through the AI Debugging Workflow once the fire is out.
Two documents plus a contained incident: a structured incident summary (step 3) for stakeholders who weren't in the war room, and a durable postmortem and changelog entry (step 4) covering cause, timeline, fix, and follow-ups. The code path is understood, but the tested fix comes later.
Work the four steps in order in your own AI tool: triage and stabilize first, understand the failing code path second, write the incident summary third, produce the postmortem last. NewPrompt supplies the prompt for each step and the resource links; you run them and own every call.
Bring the live signals you already have: the alert or error, affected endpoints or services, recent deploys or config changes, logs, and the blast radius. Step 1 uses these to scope impact and pick a mitigation; step 2 needs the relevant code path so diagnosis is grounded in what actually ran.
The incident's over and you've got a channel full of messages and logs, so "summarize this" returns a blamey story with an invented root cause. Here's how to turn your real notes into a blameless incident postmortem: confirmed timeline, evidence-backed factors, owned actions.
The order that actually finds bugs instead of guessing at them — so you end with a verified fix, not a plausible one that quietly returns next week.
A complete AI-assisted review pass — not one prompt — that ends with ranked findings, tests guarding behavior, and a refactor plan when one is warranted.
Connect systems so they don't break each other — map the integration boundaries, design the event and webhook contracts, plan retries and failure handling, then document the integration.