The workflow works, the client is happy, and you send a Slack message that says "all done." Three months later their n8n stops, you've changed your phone number, and nobody knows where the API key lives. A handover runbook is the document that prevents that call. Below is a copyable n8n client handover runbook template, with notes on why each section exists.
It assumes you built the automation in n8n for a small business. I've kept the product claims to the ones I checked against n8n's own docs on 2026-10-08. Where I couldn't confirm something, I say so.
The template is plain text on purpose, so you can paste it into Google Docs or Notion and fill in the brackets.
What goes in the runbook header?
Start with the facts someone will need at 2 a.m. or two years from now.
CLIENT HANDOVER RUNBOOK
Client: [COMPANY]
Project: [PROJECT NAME]
Version: [1.0] Date: [YYYY-MM-DD]
Prepared by: [YOUR NAME, CONTACT]
Client owner (the person who decides things): [NAME, CONTACT]
Client technical contact (if any): [NAME, CONTACT]
Purpose in one sentence:
[e.g. New enquiries from the website form are logged in the sheet and the
owner is messaged on WhatsApp within a minute.]
Business impact if this stops:
[e.g. Enquiries still arrive by email but are not logged or flagged.]
How to switch it off safely:
[e.g. In n8n, open workflow X and set it to Inactive. Manual process: ...]
The last field matters more than it looks. When something misbehaves, the client's first question is "how do I stop it?" Put the answer where they can find it.
How do you document the architecture?
One page. A reader who has never seen the build should know what talks to what.
ARCHITECTURE
Hosting: [provider, plan, region, URL of the n8n instance]
n8n version: [VERSION, date checked]
Database: [SQLite default / Postgres, where]
External services used: [list with purpose]
WORKFLOWS
| ID | Name | Trigger | What it does | Writes to | Active? |
|----|------|---------|--------------|-----------|---------|
| [ ] | [ ] | [webhook/schedule/email] | [ ] | [sheet/CRM] | [yes] |
DATA FLOW (one line per hop)
1. Website form -> webhook in workflow [NAME]
2. Workflow [NAME] -> language model step (model: [NAME])
3. Output -> Google Sheet [NAME] and WhatsApp message to [WHO]
PERSONAL DATA
What personal data passes through: [names, phone numbers, ...]
Where it is stored: [ ]
Retention: [how long executions and logs are kept]
Fill the "personal data" block honestly. If the workflow sends customer details to a third-party language model API, the client should know that, in writing. Whether that is acceptable for their situation is a question for them and their adviser, not something this template can answer.
If a language model step is inside the flow, record the exact model name and which provider account pays for it. Model providers retire and change models over time, so "which model is this using" is a question you'll want answered fast later.
Who owns the credentials?
Create a credentials register. Don't put the secrets in it, only where they live and who controls them.
CREDENTIALS REGISTER (no secret values in this table)
| Credential | Used for | Account owner | Where the secret is stored | Rotate / expires |
|------------|----------|---------------|----------------------------|------------------|
| [OpenAI-compatible API key] | LLM step | [CLIENT] | n8n credentials store | [date or "when leaving"] |
| [Google OAuth] | Sheets access | [CLIENT] | n8n credentials store | [token refresh: automatic?] |
| [Webhook secret] | Form -> n8n | [CLIENT] | n8n + website settings | [ ] |
| [Hosting login] | Server | [CLIENT] | Password manager | [ ] |
ENCRYPTION KEY
n8n encrypts saved credentials with a key. Per the n8n docs
(N8N_ENCRYPTION_KEY), you can provide a custom key, and by default n8n
generates a random one on first launch.
Where the key is stored: [password manager entry NAME]
Who has access: [CLIENT OWNER, YOU while under support]
That last block is the one people forget. If the instance is rebuilt or restored without the same encryption key, the saved credentials can't be decrypted, and you'd have to re-enter every one. The n8n docs describe the variable and the default behaviour; I haven't tested a failed restore myself, so test yours (see the backup section).
The rule I'd follow: the client owns every account, and you are a guest. You hold delegated access while under a support plan, and the runbook says how that access is removed when the plan ends. Using your own API key "to get started" is how an automation ends up depending on your credit card.
What monitoring does the client need?
Silent failure is the worst failure. n8n has a built-in answer for this. Per the n8n docs on error handling (checked 2026-10-08), you create a separate workflow that starts with the Error Trigger node, then choose it as the error workflow in the settings of each workflow you want covered. It runs when that workflow's execution fails, and one error workflow can serve several workflows.
Document what you set up:
MONITORING AND ALERTS
Error workflow: [NAME, ID] Covers: [list of workflows]
Alert goes to: [email / WhatsApp / Slack channel], recipient: [NAME]
Alert contains: workflow name, error message, last node, link to execution
Alert test: sent on [DATE] by [WHO], received: [yes/no]
HEARTBEAT (optional)
A scheduled workflow sends "n8n is alive" to [WHO] every [interval].
If this message stops arriving, check the server first (Section: Recovery).
WHAT "HEALTHY" LOOKS LIKE
Expected runs per day: [N]. If zero runs in [N hours] on a weekday, investigate.
A failure alert only fires if n8n itself is running. That's why the heartbeat exists: a missing message is a signal too. Note that if the server is down, the error workflow can't run, so the alert can't come from n8n. I didn't verify any particular uptime monitor, so pick one you've actually tested.
How should errors be handled inside the workflow?
Write the behaviour in plain language, then point to the nodes.
ERROR HANDLING RULES
- API call fails: retry [N] times with [wait], then fail the execution.
- Language model output cannot be parsed: do not send anything to the
customer. Route to the "needs a human" path and alert [NAME].
- Missing required field: stop and alert, listing the missing field.
- Duplicate trigger (same ID within [window]): ignore and log.
HUMAN-IN-THE-LOOP POINTS
- [Any message to a customer] requires approval by [NAME] until [DATE/criteria].
KNOWN LIMITS
- [e.g. Handwritten forms are not extracted reliably.]
- [e.g. Replies are only in English and Hindi.]
n8n also has a Stop and Error node that forces a failed execution under conditions you choose, which then runs the error workflow. It's useful for the "missing required field" rule. The point of the document is that the client learns the system's limits from you, not from a bad customer message.
What is the backup plan?
Say what is backed up, how often, and where it goes. Then test restoring it.
n8n's CLI documentation (checked 2026-10-08) lists these export commands. Run them inside the container if you use Docker.
n8n export:workflow --backup --output=backups/latest/
n8n export:credentials --backup --output=backups/latest/
According to that page, --backup is shorthand for exporting everything, formatted, one file per item, and the page says plainly that it covers only workflows and credentials, so a complete backup needs more (for example the database or data volume). The page also warns that --decrypted writes credentials in plain text, with all sensitive information visible, so avoid it unless you are migrating to an instance with a different key and you'll handle the file carefully.
BACKUP PLAN
What: workflows, credentials export, [database / data volume], encryption key copy
How often: [daily/weekly] By: [script/cron/hosting snapshot]
Stored where: [location NOT on the same server]
Retention: [N copies]
Last restore test: [DATE], result: [ ]
Restore steps:
1. Provision a clean n8n [VERSION] instance.
2. Set the same encryption key.
3. Import workflows and credentials.
4. Reconnect webhooks and re-activate workflows one at a time.
If you've never restored, you don't have a backup, you have a hope. Do one restore on a spare instance before handover and write down what surprised you.
Who pays for hosting?
Settle it before you build, and write it into the runbook.
| Option | Who holds the hosting account | Who pays the provider | Your role | Watch out for |
|---|---|---|---|---|
| A. Client-owned (recommended) | Client | Client | Build and support under a care plan | Client must create the account and give you access |
| B. You host, pass cost through | You | You, then you invoice | Build, host, support | You are now responsible for uptime and data |
| C. You host, flat fee | You | You | As above | Costs can exceed your fee; the data lives in your account |
Option A keeps the client's data and the automation in their hands and is the cleanest on handover. If the client needs a server and doesn't have one, a small VPS is a common choice. Hostinger's KVM plans are one example, and you should compare providers on price and region yourself. Some links on this page are affiliate links; they cost you nothing and I only link tools I'd mention anyway. If you want to see what a VPS plan looks like, here's the Hostinger VPS option. An alternative is n8n's own hosted cloud offering, which removes server upkeep but has its own pricing, which I haven't checked here. A VPS is the wrong choice if nobody on the project will patch and monitor it.
One licensing point worth reading before options B or C. n8n is released under the Sustainable Use License. The licence text on GitHub (read 2026-10-08) says you may use or modify the software only for your own internal business purposes or for non-commercial or personal use, and may distribute it or provide it to others only free of charge for non-commercial purposes. The licence text itself doesn't mention consulting or hosting for clients, but n8n's license FAQ (read 2026-10-09) does. It lists as allowed: building automations for clients on your instance, as long as n8n stays your internal tool and clients get outputs rather than access, and charging for workflow creation, setup and maintenance. It lists as not allowed: hosting n8n as a service and letting clients build workflows, or letting external users configure their own workflows through your product. So options B and C are only comfortable if clients never log in to build things, and a shared instance holding several clients' credentials is the grey area to ask n8n about in writing. I'm not a lawyer and the FAQ is a summary of the licence, so check with one before hosting instances for paying clients. Option A, where the client runs their own instance for their own business, sidesteps most of the question, though it's still worth reading.
If you do set up a server for the client, the self-hosting guide for n8n on a VPS has a Docker Compose file with Postgres and HTTPS, and the VPS hardening checklist covers what to lock down before real credentials go on it. For the build side, the n8n with the Claude API tutorial walks through setting up a first workflow.
What do support levels look like?
Define them so "can you just quickly look at this" has a price. These are example tiers with placeholder numbers to fill in.
SUPPORT LEVELS
Level 0: Handover warranty
Covers: bugs in the delivered workflows
Duration: [N] days from handover date
Price: included
Level 1: Monitoring and fixes (monthly care plan)
Covers: reviewing alerts, fixing broken integrations, updating n8n,
one backup restore check per [quarter]
Response: acknowledge within [N working hours], fix target [N working days]
Hours included: [N] per month; extra at [RATE]
Price: [AMOUNT] per month
Level 2: Changes and new workflows
Covers: anything not in the original scope
Process: written change request, quote, approval, then work
Price: [RATE] or fixed quote
NOT COVERED
- Outages at third-party providers
- Changes made to the workflows by others without notice
- Costs of third-party APIs and hosting (paid by [CLIENT])
- Behaviour changes caused by a model provider updating or retiring a model,
other than re-testing and re-prompting under Level 1 or 2
The model-change line is specific to AI workflows. Providers update and retire models, and outputs can shift as a result, so agree on a periodic spot check of real outputs and say who pays for fixes.
What does the final handover checklist look like?
Go through it on a call with the client and tick each item together.
HANDOVER CHECKLIST
[ ] Client owns hosting account, n8n login, and all API accounts
[ ] Credentials register completed (no secrets in the document)
[ ] Encryption key stored in client's password manager
[ ] Error workflow active; test alert received by the right person
[ ] Heartbeat set up (if used)
[ ] Backup run; restore tested on [DATE]
[ ] Client has seen each workflow run end-to-end with real data
[ ] Acceptance tests from the SOW passed and signed off
[ ] Support plan chosen and signed
[ ] My access: [kept under Level 1 / removed on DATE]
[ ] Switch-off steps demonstrated
[ ] 14-day check-in booked
The acceptance item ties back to your agreement. The SOW template post covers acceptance criteria and change requests, and the agency pricing post explains how to price the care plan separately from the build.
What I could not verify
I haven't run this template on a live client project, and I didn't test an n8n restore for this post. The n8n facts (encryption key behaviour, error workflows, CLI export flags, the licence wording) come from n8n's docs and GitHub, as read on 2026-10-08 and re-checked on 2026-10-09. n8n versions and docs change, so recheck before you rely on a command. Nothing here is legal advice.
