Sample document
A sample runbook
Delivered with every engagement. The structure below is genuine, with client details redacted.
Why we publish this
A documented client can change provider without disruption, which is why many vendors do not produce these.
A document covering every account, the deployment process, backup locations, and escalation contacts reduces a change of provider from a crisis to a scheduled task.
The structure is published so it can be assessed before an engagement begins.
Document
RUNBOOK — [CLIENT NAME]
Last reviewed: [DATE]
Accounts and ownership
Every account, its owner, and access route.
| Domain registrar | [REDACTED] — registered to the client | Auto-renew on |
|---|---|---|
| DNS | Managed at registrar | Records documented below |
| Hosting | [REDACTED] — client-owned account | Billed to the client, not the vendor |
| Analytics | Cookieless | Client is account owner |
| Automation platform | [REDACTED] | Client-owned workspace |
If the website is down
Ordered from most to least likely cause.
- 1. Load the site on mobile data with wifi disabled. If it loads, the fault is local.
- 2. Check the host status page, linked in the full runbook.
- 3. Confirm the domain has not expired; expiry presents identically to an outage.
- 4. Contact Cox & Co. Monitoring normally raises an alert first.
- 5. If unreachable: the host support number is in the full runbook and your account has owner access.
If forms stop arriving
A silent failure: nothing appears broken and enquiries stop.
- 1. Check spam and filter rules first; this is the most common cause.
- 2. Submit the form with a real address and see whether it arrives.
- 3. Check the sending service for delivery failures.
- 4. Report it. Silent form failures are treated as urgent.
Deployment
Written so another engineer can take over unaided.
- 1. Source lives in the client repository. Branch, change, open a pull request.
- 2. A push to main triggers a build. Build failures block the deploy.
- 3. Automated checks run on every build: contrast, SEO metadata, link integrity, duplicate content.
- 4. Rollback redeploys the previous build, in under a minute.
Backups
Backups are verified by restore, not assumed.
- 1. Content is in version control, recoverable to any point.
- 2. Form submissions go to email and are mirrored to the automation platform.
- 3. Database backups run daily where a project has a database, retained 30 days.
- 4. A restore is tested quarterly and the last successful test date is recorded.
Escalation
Contact order.
| Anything urgent | Call or text | Site down is urgent at any hour |
|---|---|---|
| Non-urgent changes | Same business day, weekdays | |
| If unreachable | Host support, via your owner account | Number in full runbook |
| Handover | This document | Written for a competent developer to pick up |
The real document also contains credential locations, support numbers, an integration inventory, and the last verified restore date. These are redacted here.