How it works · Step 4 of 4
For the person carrying the pager
Confirm: did it hold — and what we don’t claim
An action that ran is not an action that worked. The pass isn’t finished until something checks — and if the check fails, it calls the reverse steps its author wrote.
The step
For the person carrying the pager
It re-checks its own target.
After the action runs, the ActionBook checks the thing it was meant to fix. Is the service answering? Is the mount back under the line? Is the process present and staying up? These are not generic health checks. Your engineer named them when the book was written — it is your definition of recovered, not ours.
It held
The pass closes. What fired, what was checked, what ran and what the check saw go to team chat and onto the record. Nobody was woken.
It didn’t hold
It calls the reverse steps its author wrote — the current step first, then back across the steps already completed, wherever a step has a defined reverse. The event stays open instead of being marked done, and the record names what could not be undone.
This is why an action is four things and not three. A tool that fires a command and reports “executed” has told you about itself, not about your service.
Being straight about it
For whoever picks the tools
Confirming a check is not measuring an outcome.
This is where it would be easiest to write a sentence we cannot stand behind. So here is the line, drawn precisely.
Then you read it
For the person who owns the headcount
The report is the last thing the pass does.
Every pass ends in a record: the event, the check, the facts gathered, the action, the re-check and the outcome. It includes the actions it proposed and was not permitted to take — over time, the most interesting column in the table. Your oversight lives there, after the fact, the way the approval sits before it. Neither one asks you to be awake while it happens.