Lessons 89.1 and 89.2 made the operation good and affordable — while you're watching. Now the hard test: you get sick, travel, or leave, and the workflow keeps running (or breaks) without you. If everything important lives in your head, the bus factor is one and the operation is a hobby with uptime. A runbook fixes that in one page.

The vocabulary, in plain language

• Runbook: the one-page "how this workflow runs and what to do when it doesn't" — written for a competent stranger, not for you.
• Operating procedure: the normal-path steps — start, check, confirm done. Boring by design.
• Dependency: anything the workflow needs that you don't control — the CRM API, the email vendor, the secret vault, the schedule trigger. Dependencies are where outages come from.
• Recovery step: the ordered fix for each known failure — restart where, replay what, who approves. Taken from Lesson 88.4's failure cases.
• Bus factor: how many people must disappear before the operation stalls. One is an emergency waiting for a date.

The mental model: the restaurant's opening checklist taped inside the cupboard. Anyone trained can open the shop: alarm code, oven sequence, supplier numbers, what to do when the fridge dies. The chef's genius isn't on the card — but the shop survives the chef's day off.

The one page that matters

A runbook answers seven questions on a single page — nothing more:

1. Where does it run? Platform + workspace/scenario name (with links to n8n, Make, or Zapier run history) or server + repo path. 2. Credentials? Which dedicated credential (Lesson 88.3), where stored — never the secret itself, just its name and vault location. 3. Schedule / trigger? When it fires — webhook event (link EVENT-FLOW.md), cron line, or manual. 4. Logs? Where runs, errors, and the audit trail live; how far back they go. 5. Expected output? What "healthy" looks like — volume, duration, sample output. Without this, nobody can tell broken from slow. 6. Approval gate? Which steps wait for a human, and who that human is. 7. Emergency stop? The exact stop switch + kill switch (Lessons 88.4, 89.2) — button location, who may pull it, what safely halts vs. what finishes.

Keep vendor specifics generic enough to survive interface changes (durable concept first, click path second, per the editorial standard) and link official docs for the current clicks.

Exercise: write the one-pager

Produce the runbook for your highest-value recurring workflow:

# RUNBOOK — [Workflow] (one page)

- Runs where: ___ (link) | Trigger/schedule: ___ | Owner: ___ / Backup: ___
- Credentials: ___ (vault location only) | Test vs prod: ___
- Logs: ___ (retention ___) | Healthy looks like: ___ (vol/duration/sample)
- Normal procedure: 1.___ 2.___ 3.___ (5 lines max)
- Approval gate: ___ waits for ___ (SLA ___)
- If red: failure → recovery (from contract 88.4): ___ → escalate ___ 
- STOP: switch ___ / pulled by ___ / halts ___ safely / resume needs ___
- Dependencies + status pages: ___ / Last tested: ___

Worked mini-example — ByeBuy weekly publish assist: runs on a self-hosted n8n workspace (link), triggered Mondays 08:00; credential svc-content-draft in the vault; logs retained 90 days; healthy = one draft + asset list in the drafts folder by 09:00. Approval gate: editor publishes, never the workflow. If red (source fetch fails): retry per contract, then queue for editor. STOP: pause toggle in the workspace, either editor may pull; in-flight drafts finish, no auto-publish ever fires. Backup owner tested it once — found the pause button in under two minutes. That's the whole test.

Finish line: a one-page runbook a backup owner has actually used to find the logs, check health, and locate the stop switch.

Verify quickly: the away-test — hand it to your backup, leave the room, and have them answer "is it healthy right now, and how would you stop it?" If they can't in five minutes, the runbook fails.

Common failure mode: the brain-filing system — "oh, I just know." It works until the one week you're unreachable, when a stuck retry loop, an expired credential, or a full queue waits for knowledge nobody else has.

Check your understanding

1. What seven questions must any runbook answer, and why is "expected output" among them? 2. Why does the runbook name credential locations but never contain secrets? 3. What does the away-test prove that re-reading the runbook doesn't?

Next

Someone else can now keep the lights on. But some decisions should never be left to the system at all — Lesson 89.4 draws the red lines around what stays human.