The Runbook Runs In One Direction

A runbook is not a manual, and the difference is the reader. A manual is written for someone who has time to be taught. A runbook is written for 1 person in the middle of a job, tired, at 11 pm, with 1 screen open and no appetite for a paragraph that starts with the word if. The page behind this article runs 11 sections and covers a job that ends in a finished MP4, and it assumes the reader already knows why the job exists. That assumption is the design. Every line is either an instruction or a number. Install the credentials folder. Check the balance. Paste the brief. Start the run. 20 to 30 minutes of wall clock, 15 shots, 7 voice beats, 6 text beats. Nothing argues for the method, because by the time the page is open the argument has already been settled - and a paragraph of reasoning at step 4 reads as optional to a person under time pressure, which is how readers get lost in documents that were meant to be short. There is 1 test for whether a line belongs on the page. Read it to someone who has never seen the system. If the reply is a question, the line belongs in a different document. The page carries 3 tables, 1 link list and 1 gate, which is the correct weight for a document whose reader is in a hurry and whose subject is a pipeline that costs money to run twice. 1 probability sits over the form. The probability that a runbook which explains its reasoning at every step gets skipped after the first 3 lines by the very reader it was written for is high, because explanation reads as optional. The probability that the 1-page version of the same job gets followed to the end is higher, and writing the short version second costs an hour at most.

The first section of the page is section 0, and it is the section that costs the most when it is skipped. 8 API keys live in 1 file. 1 credentials folder holds the render account. 1 balance check decides whether the job is possible at all, because 1 finished piece costs 15 to 30 units and the floor for a fresh run is 75. A missing key is not discovered at step 1. It is discovered 20 minutes in, when the audio stage fails and the video work sitting behind it cannot be finished, so a 30-second check at the top removes 20 minutes and a debugging session that nobody scheduled. The time budget is published in the same breath as the steps and it is deliberately specific: 0 to 1 min for the plan, 1 to 20 min for the renders, 20 to 22 min for voice and music, 22 to 27 min for the encode. 20 to 30 minutes total, and the budget covers the whole job rather than the interesting part of it. A published budget is not decoration. It is the instrument that tells the reader whether the run is on the rails at the moment when the answer can still change what they do about it. Reading order is execution order, which is why the page never sends the reader forward for anything. 1 direction only. A runbook that points forward is a manual pretending to be a checklist, and its reader ends up holding 3 places in the document at once with 1 hand. The rule is not about tidiness. It is about the number of things a tired person can hold at the same time, which is about 2. 1 probability closes the section. The probability that a job with 8 prerequisites arranged in the wrong order runs clean on the first attempt is low, because a wrong order produces its failure at the last stage rather than the first - the most expensive place for a failure to land. The probability that the same job finishes when the cheap, slow checks run before the expensive, fast ones is higher, and arranging a page that way takes no tooling at all.

The page carries 1 rule in capitals and the rule is about concurrency. Do not run 2 renders at once. The account holds 5 concurrent slots, 15 shots go out in 3 batches of 5 at about 4 minutes a batch, and the render stage is 1 sequence from the first shot to the last. A second job does not double the throughput. It spends the same 5 slots twice, and every request that cannot find a free slot comes back with error 1303 - on both jobs, because a limit is shared before it is divided. This is the class of mistake that looks like ambition and prices like arithmetic. 5 slots shared by 2 jobs is not 2.5 slots each. It is a queue with 2 heads, 2 half-finished renders, 2 error logs and 1 afternoon gone, and the only thing that changed between the good run and the bad 1 is the order 2 clicks were made in. The same rule governs the render itself. Stills before motion. 1 frame at a time, with the 1 anchor image signed off before the second shot is paid for, so a face cannot drift across 32 shots. A pipeline run in parallel buys throughput and spends certainty, and certainty is the scarce good when the output has to hold a single identity from shot 1 to shot 32. 1 probability sits over the rule. The probability that a producer who runs 2 jobs to save time ends up with 2 jobs to repair is high, because a shared resource does not split, it queues, and both halves fail on the same tick. The probability that 1 job at a time finishes inside the published 30 minutes is higher. Entrade built 200 wood-gasification machines across the UK and Europe on that order, and the count came out of repetition rather than out of simultaneity.

Half the page is a table of failures, and the table is the part most runbooks leave out. 6 error strings are printed exactly as the system prints them, each beside 1 fix: duration value '3.5' is invalid, code 1201, which is old code and clears when the server restarts; parallel task over resource pack limit, code 1303, which means a second job is running somewhere; timed out after 60 min, which is a wait limit raised in 1 named file; fetch failed from the model provider, which is transient and clears on the next click; media load rejected by the URL safety check, which the recovery script already handles; composition not found, which is 1 wrong name in 1 line of code. The rule that makes the table useful is that every failure gets either a fix or nothing. No row ends with the word investigate, and no row ends with a shrug. Each fix names a file, a command or a click, so the reader can act without asking anyone - which matters most at the hour when the person they would ask is asleep, which is the hour most runs happen. The second rule is that the failure is written in the machine's own words rather than paraphrased. The duration value is invalid is not a searchable string. duration value '3.5' is invalid is. The 4 minutes lost to a paraphrase are lost in the wrong order too: before the fix rather than after it. 1 probability closes the table. The probability that a reader who meets an error they have seen named before resolves it inside 5 minutes is high, because recognition is faster than diagnosis. The probability that the same reader resolves a failure arriving as 40 lines of stack with no name attached is lower, and the cost of naming a failure is 1 line written once, at the moment it is first solved. A personal guarantee signed for EUR 20 million against a company that folded on Christmas Day in 2008 taught that lesson in 1 move, and the lesson was written down rather than remembered.

A runbook is not a manual. The reader is 1 person in the middle of a job, and they have no appetite for a paragraph that starts with the word if.

The page carries 1 gate with 15 rules attached, and the gate is a checklist rather than a judgement. Music starts inside 0.5 s. The first voice line lands inside 2 s and is a statement. The register stays 35 mm documentary for the whole run. No brand name appears anywhere in the copy. The fade to black sits at 56 s and never lands during a voice line. 1 voice, consistent to the last word. Every rule on that list is either met or not met, which is what makes the gate usable on a bad day, when nobody in the room wants to be the person who makes a call. Failures at the gate are repaired 1 element at a time. 1 shot that reads wrong is re-rolled on its own for 1 unit and the render runs again. It is not a reason to restart the film, and it is not a reason to re-open the brief. The same holds for a voice beat and for a text beat: the failure has 1 address, and the repair happens at that address. A checklist also makes the pass rate measurable, which is the part that changes behaviour. 15 rules, 15 checks. A run that clears all 15 is finished rather than nearly finished. A run that clears 13 has exactly 2 items outstanding, and those 2 items are the whole to-do list - a different state from the 1 a tired reader would describe out loud as basically done. The habit behind it is older than the pipeline. Taking a company through a Frankfurt IPO and deploying 210 energy systems across Africa and Asia both ended in the same place: a written list of what has to be true before the work counts as delivered. 1 probability sits over the gate. The probability that a run judged by feel passes on the nights when it matters least and fails on the night it matters most is high, because judgement tracks mood. The probability that 15 written checks hold their line at 11 pm is higher, and the list was written on the first quiet morning rather than the third bad night.

The last third of the page is recovery, and recovery decides whether a runbook gets used a second time. When the encode fails after the shots have landed, the recovery command reads the state out of the database and redoes 2 steps: the copy and the render. 5 minutes. The alternative, starting from the brief, is 30 minutes plus another pass through the account's 5 slots, and it throws away 15 shots that were already fine. When 3 of 15 shots come back empty, the finalize script submits the missing 3 and nothing else. The rule in both cases is the same. Resume at the failure, never at the start. A runbook that documents only the happy path is used once and then abandoned. A runbook that documents how to resume is the reason the job gets run again on a bad night, by a person who is already tired. The runbook also names the output before the run begins: 1 folder, 1 file name derived from the campaign angle, 1 review pass in a player, then 1 upload with a visibility decision made in 2 stages - unlisted, watch it once, public. Nothing in that sequence is creative, and that is the point of putting it on the page. The creative decision happened in the brief. Everything after the brief is order. 1 last probability, and then the page ends where it started. The probability that a job with a named output path and a written resume command gets finished by the person who started it is high, because the remaining work is small, written down and 1 click wide. The probability that the same job finishes when it lives in 1 head at the end of a long day is lower, and the repair for that is 1 page. Decide the structure. Lock the identity. Build the conditions. Run 1 unit at a time, and refuse to assemble early. The page runs in 1 direction. Read it that way and the job is 30 minutes.