Runbooks and approvals

Runbooks → New runbook. A runbook has a name, a description, and an ordered list of steps. Admins author and edit; developers execute.

Write for the person who will run it at three in the morning without you. State what each step does and what "it worked" looks like, not just what to type.

Every save creates a version containing a snapshot of the whole document, so history survives even if the current version is rewritten entirely. The runbook page lists every version with its author and timestamp.

On Pro and above you can restore a previous version. A restore creates a new version equal to the old one rather than deleting anything - "we reverted the deploy runbook on the 14th" stays visible.

A runbook can be marked as requiring approval. Executing it then creates a pending execution and notifies the project's approvers rather than running.

An approval names a specific execution, not the runbook. Approving one run does not approve the next, and an approved execution that is never started simply expires unused.

Each execution records who ran it, which version they ran, when it started, whether approval was required and who granted it, and how it ended. The CLI reports completion back, so an execution that started and one that finished are distinguishable.

A run interrupted by the machine going away is reconciled automatically after an hour and marked as interrupted rather than left running forever.

Credentials a step consumes are brokered and audited individually. A runbook is not a way to obtain access you could not otherwise have - it runs as you, with your permissions.

Free allows ten runbooks; every paid tier is unlimited. Executing runbooks from the CLI is available on every plan, including Free. Reading and restoring version history requires Pro.