Implementation worksheet · 5 min read
A Production Incident Handoff Template for Solo Founders
Capture nine things during the incident rather than after: when it started and how you found out, what users experienced, what you have confirmed is true, what you have ruled out, what you changed (each action, timestamped), what is still unknown, what is currently mitigating it and whether that is temporary, what must be undone later, and the next thing you were about to try. Written as you go, in a single file. The field that pays for the whole exercise is what you ruled out — without it, the second pass at 2am repeats the first pass's investigation, because tired-you does not remember which theories were already eliminated.
Incident handoff templates assume a team: someone hands to someone else at shift change. Solo founders have the same problem with a different shape — you hand off to yourself after sleep, or to a contractor next week, or to a customer asking what happened. Reconstructing an incident from memory two days later produces a confident and partly fictional account.
Put it into practice
1. Open the file at minute zero, before investigating
One file, appended to, timestamped. The instinct is to fix first and write later, and later is when the details are gone. Two lines at the start — what you saw, when — cost ten seconds and anchor everything after.
2. Record user impact separately from system symptoms
'Checkout returns 500 for all users' is the system. 'Nobody could pay for 40 minutes' is the impact. The second is what a customer email needs, what the severity decision rests on, and the part reconstructed least accurately from memory.
3. Log every action with a timestamp, including the ones that did nothing
Restarted the worker. Rolled back the config. Cleared the cache. Each with a time and what happened after. This is what lets you distinguish a fix from a coincidence, and it is the only defence against the classic mistake of crediting the last thing you did.
4. Keep a ruled-out list as its own section
Theories eliminated, and how. This is the field that prevents the second session repeating the first. It is also what you hand a contractor so they do not spend an hour on something you already checked.
5. Mark mitigations as temporary and write the undo
Scaled something up, disabled a feature, hardcoded a value to get service back. Each needs a line in an undo list with enough detail to reverse it. Temporary mitigations become permanent through forgetting, and the one that costs money is discovered on the next invoice.
6. Write the next step before you stop
The last line before sleep is what you were about to try and why. Resuming from a blank page means re-deriving context that took an hour to build, and re-deriving it while tired is where wrong conclusions come from.
7. Convert the file into the customer message and the fix
The impact line becomes the customer communication. The undo list becomes tomorrow's tasks. The ruled-out list becomes the start of the postmortem. Written once, during, it serves three purposes; reconstructed after, it serves none of them well.
The handoff file
Copy this structure into your review document and record your observed result for each row.
| Field | Captured | Notes |
|---|---|---|
| Started at / detected at / how detected | ||
| User impact, in user terms | ||
| Confirmed true | ||
| Ruled out, and how | ||
| Actions taken, timestamped | ||
| Still unknown | ||
| Current mitigation | ||
| Is the mitigation temporary? | ||
| Undo list | ||
| Next thing to try | ||
| Customer message sent? |
A failure worth checking
The forgotten temporary mitigation. At 1am you scale a resource up or disable a check to restore service, fully intending to revert it tomorrow. Tomorrow the incident is over and the note exists only in your memory. It surfaces months later as an unexplained cost line, or as the disabled check that would have caught the next outage. The undo list is one line written while you are already in the file.
Common questions
Is this overkill for a one-person project?
The opposite — a team has other people's memory as redundancy and a solo founder has none. Ten minutes of writing during the incident saves an hour of re-deriving and prevents the mitigation you forgot to reverse.
What if the incident resolves itself?
Write it up anyway, and mark the cause as unknown rather than assuming it is gone. A self-resolving incident is usually a recurring one with a trigger you have not identified, and the file is what makes the pattern visible the second time.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.