> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to write a runbook for a critical process
- URL: https://blog.jestor.com/write-a-runbook-for-a-critical-process/
- Published: 2026-09-16T18:55:55.000Z
- Updated: 2026-09-16T18:55:55.000Z
- Author: Bruno Bannach

To **write a runbook** that works, it has to be usable by someone who has never done the task, under pressure, without asking anyone. In **Jestor**, a runbook can live as a document attached to the process it describes, so it is found where the work happens.

## Why runbooks fail when they are needed

A runbook is written by the expert, who omits everything obvious to them. It is then read for the first time by someone unfamiliar, during an incident, with everyone waiting.

The gaps become apparent at exactly the worst moment.

Where runbooks are essential:

- Processes that run rarely but must not fail
- Anything performed during an incident
- Month end and year end procedures
- Tasks only one person currently knows
- Anything with regulatory consequences

## What a usable runbook contains

| Element                    | Why                                 |
| -------------------------- | ----------------------------------- |
| When to use it             | So the right one is chosen          |
| Prerequisites              | Access and information needed first |
| Numbered steps             | Followable without interpretation   |
| Expected result per step   | Confirms it worked                  |
| What to do if a step fails | The most commonly missing part      |
| Who to escalate to         | By role, with a fallback            |

## Step by step to write one

1. **Write it while performing the task**, not from memory.
2. **State the prerequisites first**, including access.
3. **Number every step**, with no step containing two actions.
4. **State the expected result** of each step.
5. **Describe what to do when a step fails**, which is where most runbooks stop.
6. **Name escalation by role**, with a fallback.
7. **Test it** by having someone unfamiliar follow it while the author stays silent.

## Why the silent author test is the only real validation

An author present during the test will answer questions instinctively, which proves nothing. Requiring them to stay silent, and noting every point where the reader gets stuck, produces the list of gaps directly. It is uncomfortable and it is the only reliable method.

## Why choose Jestor

In **Jestor**, runbooks can be documents attached to the process they describe, so they are found in context rather than in a separate repository. Review cycles can be recurring tasks with owners, and the steps can be built as a checklist with subtasks where the process runs inside the platform.

## Frequently Asked Questions

### When should a runbook be written?

While performing the task, since writing from memory omits what feels obvious. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### What is most often missing from a runbook?

What to do when a step fails.

### How do I know a runbook works?

Have someone unfamiliar follow it while the author stays silent.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.