What is a runbook in Octopus Deploy, and when would you use one instead of adding a step to the project's deployment process?

## The gap runbooks fill Before runbooks existed, teams that owned an Octopus instance had a good tool for deployments and nothing for everything else. Restarting a service in Production, rotating a certificate, restoring last night's database backup into Test, running a failover drill — all of it was either manual work over remote sessions or, worse, a fake deployment: a project with no real artifact whose only purpose was to run a script. That second workaround is the thing runbooks were built to kill, and naming it is a good sign in an interview answer. A **runbook** is a separate process defined inside a project. It has its own ordered steps, drawn from the same step library the deployment process uses — run a script, run against a role, call a cloud API — and it executes against the deployment targets of an environment you select when you run it. What it does *not* do is create a release, consume a package version, or advance anything through a lifecycle. It is operational work, not shipping. ## Deployment step or runbook? The dividing question is simple: **is this task part of shipping this version, or is it something you need to be able to do at any time?** Work that belongs in the deployment process is work that is meaningful only in the context of a specific release — applying the migration that ships with this version, transforming configuration files as the package is unpacked, warming a cache after new code lands, running smoke tests against what was just deployed. Its inputs come from the release, and running it without a release makes no sense. Work that belongs in a runbook is work whose trigger is operational: an alert fired, a certificate is expiring, support needs the Test database refreshed, the quarterly DR drill is due. Its correctness does not depend on which version is currently deployed, and forcing it through a deployment would mean inventing a release just to get a script to run. There is a middle case worth mentioning: infrastructure provisioning. Many teams keep environment setup — creating a queue, provisioning a database, configuring DNS — as runbooks so the environment can be built or rebuilt without any application release existing yet. ## Publishing and snapshots Runbooks follow the same snapshot discipline as releases, which is the detail candidates most often miss. You edit a runbook as a draft, and you **publish** it to produce a snapshot of its process and variables. Runs use the published snapshot. If you edit a runbook and the next run behaves as before, the near-certain cause is that you never published — the same reproducibility principle that makes a release immutable, applied to operational work. It matters more than it sounds: the thing you tested when you wrote the runbook is the thing that fires at 3am. ## Scheduling and permissions Two capabilities make runbooks more than a script drawer. **Triggers** let a runbook run on a schedule — nightly backups, a weekly cleanup, a periodic health check — without anyone driving it. That converts recurring toil into a versioned, auditable, logged process instead of a cron job on someone's server that nobody can find. **Permissions** are separate from deployment permissions. You can allow a support team to run the "restart the web service" runbook in Production while giving them no ability whatsoever to deploy code there. This is the real organisational payoff: the people who respond to incidents get exactly the buttons they need, safely, and every press is logged with who did it and what the output was. In a shop where deployment approval is heavyweight, this is what stops routine operations from being tunnelled through the deployment approval path. ## What to say in an interview Give the definition, give the dividing question, then give one concrete example on each side — a database migration shipping with the release versus a certificate rotation that has to happen on its own schedule. If you can add that runbooks need publishing, that they can be scheduled, and that they carry their own permissions so operations does not require deployment rights, you have covered everything an interviewer is checking. The underlying point is the one this whole product is built around: shipping a version and operating a system are different activities with different approvers, and they deserve different objects.