Runbooks that match reality
Procedures for the failures that actually occur in this system, written from real incidents, not a generic template. Each one names the signal, the diagnosis, the action, and the escalation.
Working structure
Operational handover checklist.
Handover is the point where most engagements quietly fail. The code transfers, the knowledge does not, and the receiving team spends a year reverse-engineering decisions nobody wrote down.
This checklist describes what has to be true before a team can genuinely operate a product rather than merely possess it.
Build your briefFORMATMarkdown checklist
USED ATEngagement close
OUTCOMEClient-owned operation
01 / WHAT TRANSFERS
Six things, all verifiable.
Each item is written so that it can be demonstrated rather than asserted.
Alerting tied to user impact
Alerts that fire when users are affected, routed to someone who can act. Alerting that fires on infrastructure noise trains teams to ignore it, which is worse than no alerting.
Access and secrets
Ownership of accounts, credentials, certificates, and signing keys transferred and verified by the receiving team logging in without assistance. Rotation responsibility named.
Dependency and cost inventory
Every third-party service, licence, and hosting commitment, with renewal dates, cost owner, and the consequence of each one lapsing.
Escalation path
Who is called, in what order, with what authority, and what they are permitted to decide during an incident without waiting for approval.
Supported operating period
A defined window where the receiving team runs the system while the outgoing team is still reachable. This is the only part of handover that reliably transfers judgement rather than facts.
02 / HOW IT IS RUN
Handover is a phase, not a meeting.
- 01
Name the receiving owners
Before anything transfers, the product, technical, and operational owners on the client side are named. Handover to an unnamed team is not handover.
- 02
Transfer in the open
The receiving team performs deployments, responds to alerts, and makes changes while the outgoing team observes and corrects, rather than the reverse.
- 03
Exercise the failures
Walk through the incidents the runbooks describe. Gaps in a runbook are found by using it under mild pressure, not by reviewing it.
- 04
Verify access independently
The receiving team proves it can reach every system without the outgoing team present. Anything that fails here is a live risk, not an administrative detail.
- 05
Close with a written record
What transferred, what remains open, who owns each open item, and the date each will be resolved.
Sample working structure
Take the checklist.
The Markdown file carries the checklist items and prompts described above, ready to adapt to your operating model.
03 / QUESTIONS
Handover questions.
What should an operational handover include?
Runbooks for the failures that actually occur, alerting that maps to user impact, access and secret ownership transferred and verified, a dependency and cost inventory, an escalation path with named owners, and a period where the receiving team operates the system with support still available.
When should handover planning start?
At the beginning of the engagement, not the end. Handover is a property of how the work was done. Deciding at the close that knowledge should transfer is too late to change whether it can.
How do you know a handover actually worked?
The receiving team resolves a real incident without the outgoing team. Until that has happened, the handover is a document rather than a fact.
What if the receiving team is not staffed yet?
Then the handover date is not real. It is better to say so early and agree an interim operating arrangement than to transfer responsibility to a team that does not exist.
Next decision
Plan the handover first.
Ownership is designed at the start of an engagement, not negotiated at the end.