# The incident retro pack **A free pack from Perform.** For turning a 300-message thread into a postmortem. **Free and provided as is, with no warranty. It runs in your environment and sends nothing to Perform. It is not legal, tax, security or accounting advice. Treat anything you point it at as untrusted input. Full terms at the end of this file.** --- ## How to use this Copy everything below the second line into Claude, ChatGPT, Copilot or whatever assistant you already use, then paste your chat thread, the alerts and the deploy log in the same message. That is the whole setup. No account, no install, nothing to configure. If you would rather have it installed and available every time, the same pack is on the page you downloaded this from as a Claude Skill. --- ## What this does The incident is over. The write-up is due, everyone is tired, and the worst part is not the analysis. It is reconstructing what actually happened out of a chat thread nobody wrote for that purpose. Do the timeline first. Everything else gets easier once the sequence is straight, and most retros go wrong because the analysis started before the sequence was settled. ## What to give it Paste in this order: 1. The chat thread, exported or copied. Messy is fine, and the more of it the better. 2. The alert or monitoring output, if you have it. 3. The deploy or change log for the window. Strip customer names and personal data before you paste anything anywhere. If you only have the thread, say so, and the timeline will be built from that alone with the gaps marked. ## When to stop short **Check this at the end of Step 2, not before Step 1, because you cannot answer it until the timeline exists.** Stop there if the window from first symptom to recovery is under ten minutes and somebody positively confirmed no customer was affected. Unmeasured impact does not qualify, because "nobody checked" is not the same finding as "nothing happened". When it does qualify, give the timeline, the trigger, and one line saying no retro is needed. Not every incident earns a document, and a process that produces the same weight of paperwork for a blip and for an outage is one people route around. ## Step 1. Build the timeline From the thread, the alerts and the deploy history, produce one table in time order. Use the timestamps you are given. Convert everything to one timezone and say which. | # | Time | What happened | Who | Where it came from | |---|---|---|---|---| Number the rows. The five moments and the questions later both need to point at specific rows. Rules that keep the timeline honest: - **Separate what happened from what people believed at the time.** "Cache cleared" is an event. "We thought it was the cache" is a belief, and beliefs go in their own rows marked as beliefs. The gap between the two is usually where the real finding is. - **Find the five moments** and note which row number each one is. Do not add markers inside the table, because they have their own section in the write-up. The five: when it started, when the first alert fired, when the first human reacted, when the person who could actually fix it knew an incident was running, and when customers stopped being affected. Machine detection and human reaction are separate on purpose, and the gap between them is usually the cheapest thing to fix. The fourth one is worded carefully: the person who could fix it often had the causal knowledge all along and was missing only the news that something was wrong. If any moment is absent from the thread, that absence is a finding. - **Note the gaps that matter.** A fixed threshold catches the wrong silences. The ones worth a row are any silence where nobody had accepted ownership, and any silence noticeably longer than the thread's own rhythm up to that point. Silences are usually people working in a terminal, and that work is invisible to the retro unless someone asks. A quiet stretch after the incident closed is not a gap. - **Never guess a time.** If the thread does not say, write unknown. - **If the inputs carry no calendar date, say so once at the top.** Most exported threads do not have one. Write "date unknown", make retrieving it the first action in Step 4, and express every date in the actions table as days from the retro, because all of them depend on it. - **Mark a self-reported time as self-reported.** The most load-bearing timestamp in most incidents is someone saying later "I deployed at 09:05". That is neither a timestamp you were given nor a guess. Record it, and put the provenance in the source column, because if it turns out wrong the whole sequence moves. - **Where two accounts of the same thing disagree, say so in the row.** A deploy log against a person's recollection, or one person's 09:34 message against their own 10:07 message. Both count, and the second kind is more common and easier to miss, because a single input contradicting itself still reads as one consistent source. A contradiction is a finding. ## Step 2. Separate the trigger from the contributing factors The trigger is what made it start now. The contributing factors are what made it possible, and what made it last as long as it did. Most write-ups name the trigger and stop, which is why the same incident happens twice. - **The trigger.** One sentence. - **How the trigger was confirmed.** Say what actually established it. If the only evidence is that the rollback worked, write that down. Under time pressure a plausible story plus a successful rollback becomes fact within minutes, and every action below inherits whatever confidence you record here. - **What made it possible.** The condition that was already true before today. - **If the thread says this has happened before, go and get that one.** Somebody saying "second time this year" out loud is the highest-value thread in the whole document. Read the earlier write-up, and check whether its actions were ever completed. If you cannot reach it from what you were given, say which incident you are looking for and what you would check in it, and make retrieving it an action. Do not write the recurrence up as if you had read the first one. An action list that repeats one from six months ago is a different and more useful finding than a fresh list. - **What made it last.** Detection time, access, missing runbook, an alert that pointed the wrong way, one person being the only one who could do it. - **What limited it.** State this. If something worked, it is going to be defended in a budget conversation later. Write the causes about the system and the situation. A contributing factor is never a person, and if a name appears in the cause sections the analysis has gone wrong. **Credit is allowed to be personal.** If two people's judgement is why this was short, say who and what they did. Laundering that into role language makes the section vaguer and slightly dishonest, and it removes the only incentive anyone has to disclose their own change early. Blame is never personal. Credit always can be. ## Step 3. Name the three questions this retro is about to skip This is the part worth the download. Look at what the thread does NOT contain, and produce the questions nobody in it thought to ask. Draw from what is genuinely absent, not from a generic list. The ones that usually apply: - **The near miss.** What almost went worse, and what stopped it. If the thread shows someone about to run a command they then thought better of, that is the most valuable line in the whole incident. - **The blast radius nobody checked.** What else shares the failed component, and whether anyone looked. - **The silent recovery.** Whether anything self-healed, because a self-heal nobody understands will fail differently next time. - **The detection question.** Whether you found it or a customer did, stated plainly. - **The second incident.** Whether the fix introduced anything, and whether anyone is watching for it. - **The decision nobody made.** A point where the situation changed and nobody explicitly decided anything, which is how incidents drift. Pick the three that this incident actually needs, and say why each one matters here. If you had more than three real candidates, list what you cut in one line each so nothing is quietly lost. Those cut lines go in the write-up under the same heading as the three you kept, below them, so they stay in the document without competing with the three. ## Step 4. Write the actions Each action gets an owner, a date, and the specific contributing factor it addresses. Anything with no owner is a wish and should be written as one so nobody pretends otherwise. **The table ships as proposed, not as agreed.** You are writing names and dates for people who have not accepted them. Label it proposed, and confirm each owner before this is filed anywhere. Handing someone a dated commitment they first learn about in a published document is how a good retro makes an enemy. Put the retrieval and verification actions first, in the order the rest of the document depends on them: the calendar date, the earlier write-up, confirming the trigger, measuring the impact. None of those reduces frequency, duration or cost, and forcing them into one of those buckets writes a false pattern line. Sort the remaining actions by whether they reduce how often this can happen, how long it lasts, or how much it costs, and count only those when you name the pattern. Three of one kind and none of the others is worth naming out loud. ## Step 5. Write the paragraph for people who were not there This is the one paragraph everyone outside the incident will read, and it is the hardest writing in the document, so it gets its own step. Plain language. No component names, no internal jargon, no clock times. Duration in plain words, so "about forty minutes" and never "09:14 to 09:58". What someone using the product would have noticed, and for how long. If the impact was never measured, say that it was not measured, which is different from saying there was none and different again from alarming anyone. "Nobody checked at the time and nobody has checked since" is an honest sentence and it usually turns into the most useful action on the list. ## Step 6. Assemble the write-up ``` # [What broke], [date, or "date unknown"] ## What customers experienced [The paragraph from Step 5.] ## Duration and reach [The five moments from Step 1, in a small table, with the total window. Each row cites the timeline row it came from, so a reader can see which rows were load-bearing. This is the home for them, so do not restate them as commentary inside the timeline.] ## Timeline [The table from Step 1] ## Trigger [One sentence.] ## How confident we are in that [The confirmation line from Step 2. If the only evidence is that the rollback worked, it says so here, where anyone reading the actions can see what they rest on.] ## What made it possible ## What made it last ## What limited it ## Who made this shorter [The named credit from Step 2. Its own heading, because a credit buried inside a causes section does not get read.] ## Questions we are not answering yet [The three from Step 3, with why each matters] ## Actions **Proposed, not agreed. Confirm every owner before filing this.** | Action | Owner | Date | Addresses | ## What we are not doing, and why [The thing someone will suggest. Say now why it is not the plan.] ``` That last section stops the same suggestion coming back every quarter. --- ## Terms This pack runs in your environment, on your data. Nothing is sent to Perform, and Perform receives no data from it at any point. It is provided free and as is, with no warranty of any kind. It is not legal, tax, security or accounting advice, it is not an audit and it is not an attestation, and no professional relationship is created by downloading or using it. You are responsible for reviewing it before you run it, and for any decision you make with its output. Anything you point this at should be treated as untrusted input. A document, a repository or a chat thread can carry instructions aimed at a model. Licensed under Apache-2.0, which includes a disclaimer of warranties and a limitation of liability. Version 1.0, 28 August 2026. Security contact: privacy@totalperform.com, acknowledged within five business days.