Custom Runbooks
Controlled reusable COMMAND, WAIT and VERIFY workflows.
Step types
- COMMAND: sends one validated CLI line.
- WAIT: pauses the workflow for the configured interval.
- VERIFY: runs a read-back command and requires success.
Limits
| Limit | Value |
|---|---|
| Maximum steps | 40 |
| Maximum variables | 16 |
| Maximum targets | 500 |
| Maximum concurrency | 16 |
Approval boundary
Saving any change returns a Runbook to Draft. Approved Runbooks can be executed according to role/action policy. Scheduled execution additionally requires the Runbook's Allow scheduled execution policy.
Validation
Commands must remain one CLI line without unsupported control characters. Variables must be declared. Rendered commands are validated again after substitution so user input cannot bypass the Runbook's command boundary.
Failure policy
Runbooks carry an explicit failure policy, maximum targets and concurrency. Execution uses the same per-device coordination model as normal Jobs.
Definition, approval and immutable execution
A runbook contains metadata, typed variables, COMMAND, WAIT and VERIFY steps, target policy and concurrency limits. Every edit returns the definition to Draft, invalidating earlier approval. Approval is therefore tied to the exact workflow that was reviewed.
Before a Job is created, variables are validated and substituted and the fully rendered workflow is copied into the Job payload as a snapshot. A later library edit cannot change work that is already queued. Each target executes its steps sequentially inside one serialized SSH session, while the per-device coordinator prevents another operation from overtaking it.
Scheduled safety
- The runbook must still be Approved when the schedule fires.
allow_scheduledmust be enabled.- Target limits are re-evaluated when the Job is created.
- Site or Group growth cannot silently expand the approved blast radius.