Renewing the certificate. Restoring the database from a backup. Getting the printer to talk to the network again. Resetting the thing after the update breaks it. The specific sequence of clicks that makes the tax portal accept the file.
Each of these took you forty minutes the first time, mostly spent finding the answer. Each of them takes about forty minutes every subsequent time, because you did not write the answer down, and the reason you did not is always the same: at the moment you solved it, you were relieved and late and moving on.
The shape of the loss
The tell is a specific feeling. You start a task and think I have done this before — and then discover you remember having done it, and not how.
Partial memory is worse than none, because it makes you confident enough to start without looking it up, and then you spend twenty minutes retracing your own steps to reach the point where you concede you have forgotten. The knowledge decayed into an index entry with no page behind it.
This happens with anything you do more than once and less than monthly. More often than monthly and you retain it; less often than yearly and you accept looking it up. The band in between is where a personal runbook pays, and it is a wide band.
The ninety seconds
Immediately after it works, before you move on. Not later.
The exact commands or clicks, in order. Copied, not paraphrased. The real flags, the real menu names. A paraphrase is a description of the solution; the literal steps are the solution.
What did not work. One line. The obvious approach that failed, so next time you skip it — this frequently saves more time than the working steps, because next time you will have the same wrong instinct.
The thing that was not obvious. There is always one. The setting in a different menu, the order that matters, the fact that it has to be done twice. This is the line that took you thirty of the forty minutes.
Where you found the answer, if it came from somewhere. A link, an issue number, a person's name.
Ninety seconds while it is fresh. The same window as an incident timeline and for the same reason: understanding starts unloading the moment the pressure comes off.
Write it for a stranger
The mistake that makes runbooks useless is writing them for the person you are right now, who has all the context.
"Restart the service" is a note by someone holding the whole picture. In eight months you will not know which service, on which machine, or how one restarts it here. Write the machine, the exact command, and the check that tells you it worked.
The test: could you follow this at 2am, tired, having forgotten everything? That standard sounds excessive for a personal note and it is exactly right, because 2am and having forgotten everything is the realistic condition of use. Nobody consults a runbook on a calm afternoon when they remember how it works.
Length is not the fix — most good runbooks are eight lines. Specificity is.
What deserves one
Anything you have now done twice. Twice is the threshold, and it is worth being mechanical about it. The second time you solve something, you have proof it recurs, and you are holding the answer.
Anything that only happens once a year. Tax filings, renewals, the annual report, the certificate. You will forget completely, guaranteed, and there is no possibility of retaining it.
Anything you do under pressure. When something is broken and people are waiting, working from a written sequence is dramatically better than improvising from partial memory — that is the whole reason runbooks exist in operations.
Anything involving a system with a bad interface. Government portals, banking, enterprise software, anything where the correct sequence is arbitrary and undiscoverable. These are pure runbook material, because nothing about the interface will remind you.
Where they belong
Personal ones in your own notes. Findable by search, because you will not remember what you called it — you will search for the error message or the tool name. That means search has to reach inside code blocks, which is where the commands are.
Shared ones in the shared place. If a colleague could need it, it belongs in the team's documentation. Keeping operational knowledge in a personal file makes you a bottleneck, and being a bottleneck feels like job security and is actually just being interrupted a lot — the thing a handover document exists to unwind.
When you use it, fix it
The maintenance rule, and it is the only one.
Follow your own runbook and something will be slightly wrong — a menu renamed, a flag deprecated, a step no longer needed. Fix it then, in the two minutes you are already there. Not later.
A runbook corrected on each use stays accurate indefinitely. One never revisited rots, and a rotted runbook is worse than none: you follow it, it fails halfway, and now you are debugging both the problem and the instructions.
The honest version
Nobody writes these at the moment of relief. That is the entire difficulty and no amount of agreeing with the principle changes it.
The one intervention that works is making the writing take ninety seconds instead of ten minutes. Paste the commands, add two lines, done. Any attempt at a proper document — a title, a structure, an explanation of the system — is a ten-minute job, and ten-minute jobs do not happen at the moment you have just fixed something and are already late.
Cyanote is a reasonable home for these: code notes with syntax highlighting and language detection for the commands, prose notes with code blocks inline when you need explanation around them, and ⇧⌘F searching the body of everything including the code — so the error message you paste today is what finds this note in eighteen months. It is one local database on your own Mac, which for the set of instructions that make your own machines and accounts work is where it should be.