What is a runbook?

A runbook is the written steps for a procedure a team runs again and again. A daily health check, a deploy to production, a set of tests before a release, a performance check when something feels slow. The runbook says how to run it, in order, what to check afterwards, and which rules apply, so anyone can run it the same way, including an AI assistant.

What goes in a runbook

• What it is for: what it checks or does, and why.
• The steps, in order: a script to run, a command, or what to do by hand.
• The checks to make afterwards, so you know it worked.
• The rules that govern it, such as "triple confirmation before a live database write".
• When it runs: on a schedule, or only when needed.

Why runbooks matter more with AI assistants

A person who has deployed a hundred times remembers the step that is easy to miss. An AI assistant starts each session fresh. Without a runbook it works the steps out again, and may skip the one that matters. With one, it follows the same steps every time, and a log of each run shows what was found.

How fenbs keeps them

In fenbs, runbooks are Routine Processes. There are four kinds: routine, on a schedule every so many days; ad hoc, when needed; deploy, the steps to deploy; and testing, predefined test steps. Each has its steps in order, the checks to make afterwards, and links to the Decisions and rules that govern it.

Every run is logged: OK, Issues found or Failed, with notes and the tasks filed from it. A routine that is due shows in Waiting on you in the AI context. Before deploying or testing, a connected assistant finds the matching process over MCP, follows it, and logs the run.

fenbs keeps how to run it. It never hosts or runs the code: the script stays in your project, and you or your assistant run it.