Learn n8n - Operational Readiness & Runbooks

#Introduction

In episode 18 your workflows are living in Git and deployed via CI/CD pipelines. But managed code doesn't mean a system ready for operations. "Ready" means that when the payment workflow stops working at 3 a.m., someone knows what to do, who owns it, and how to recover it — without opening outdated documentation.

In this episode we build the operational foundation:

1. Runbooks: documented procedures for incidents and recovery.
2. SLAs and ownership: who is responsible for each workflow.
3. Backup, restore, and disaster recovery that can genuinely be executed.

#Runbooks: Living Operational Documents

A runbook is a step-by-step procedure for handling recurring situations — especially ones that are rare but high-risk. Without a runbook, every incident starts from zero; with a runbook, an incident becomes a checklist that even new people can run.

A simple runbook template for one workflow:

id: runbook-order-sync
judul: Order Sync Gagal
service: workflow-order-sync
sla_target: 30 menit
severity: P2
langkah:
  - Buka dashboard monitoring dan cek status terakhir.
  - Buka execution yang gagal di tab Executions UI.
  - Periksa error message dan node mana yang gagal.
  - Coba retry manual lewat tombol execute.
  - Jika tetap gagal, cek status API vendor dari luar.
  - Eskalasi ke owner bila tidak pulih dalam 30 menit.
rollback:
  - Nonaktifkan workflow aktif dari UI.
  - Alihkan webhook ke endpoint cadangan.

What makes a runbook "living" isn't perfect content, but its cycle: tested during drills, updated after incidents, and reviewed every quarter. A runbook never opened again is a dead document that gives false reassurance.

#SLAs, SLOs & Ownership

An SLA (Service Level Agreement) is a promise about service level, while an SLO (Service Level Objective) is a measurable target. For workflows, commonly used metrics: percentage of successful executions, average latency, and how quickly it recovers when it fails.

Assign a single object of ownership to every workflow — not two, not "the whole team":

workflow: order-sync
owner: tim-platform
backup_owner: tim-integrasi
slo:
  success_rate: 99.9
  max_latency_menit: 5
  rpo: 24 jam
  rto: 4 jam

A common RACI convention: the owner is fully responsible for changes and fixes, the backup_owner substitutes when the owner is away, and others are only consulted or informed. Record these SLOs near the metrics (the foundation from episode 13) so there's no discrepancy between promises and reality.

#Backup: Workflows, Credentials & Database

n8n backup must cover three different layers, because restoring only one isn't enough:

• Workflow definitions — the latest versions in the Git repository are already your first backup.
• Encrypted credentials — stored in the database, decrypted with N8N_ENCRYPTION_KEY.
• The database itself — contains execution history, tags, and other metadata not in Git.

A routine backup script that stores all three to object storage:

n8n export:workflow --all --output=./backup/workflows --pretty --decrypted
n8n export:credential --all --output=./backup/credentials --decrypted
pg_dump --host=localhost --dbname=n8n --username=n8n --file=./backup/n8n.sql
rclone copy ./backup s3:backups/n8n/$(date +%F) --progress

Three things often forgotten:

• Store backups outside the instance — the same disk as the database doesn't help when the server dies.
• Back up N8N_ENCRYPTION_KEY together with the credentials. Without that key, even decrypted credential files are useless.
• Schedule with a cron or scheduler separate from the workflows being backed up, so an n8n failure doesn't also kill its backup.

#Restore & Disaster Recovery

Restore is the real test of a backup. For a new instance, the flow: install the same n8n version, set N8N_ENCRYPTION_KEY to the same key, then import everything:

n8n import:workflow --separate --input=./backup/workflows
n8n import:credential --all --input=./backup/credentials
psql --host=localhost --dbname=n8n --username=n8n --file=./backup/n8n.sql

Disaster recovery isn't just about the restore commands, but also the numbers: RPO (Recovery Point Objective) how much data loss is acceptable, and RTO (Recovery Time Objective) how fast the service must recover. The example above uses an RPO of 24 hours and an RTO of 4 hours — meaning daily backups are sufficient, and the restore process is measured in hours, not days.

Test a drill at least once a quarter: restore into an empty environment and run smoke tests. A backup never tested is the same as having no backup.

#On-Call: Facing an Incident

When an incident genuinely happens, follow a disciplined sequence:

1. Read the runbook first — before touching anything, confirm the situation actually matches the scenario.
2. Gather facts — screenshot the failed execution, note the time, node version, and error message.
3. Act by priority — restore the service first, analyze the root cause afterward.
4. Record the timeline — when done, write a short postmortem and update the runbook with new findings.

The alerting from episode 13 and error workflows from episode 7 are your eyes: alerts inform you early, error workflows preserve failure context, and runbooks tell you what to do. These three are one system, not three separate things.

#Closing

Operational readiness turns n8n from a tool that "works" into a service that is "maintained":

• Runbooks document incident and recovery procedures so anyone can run them.
• SLAs and SLOs make service promises measurable, with clear ownership per workflow.
• Backup covers workflow definitions, credentials, and the database — stored outside the instance.
• Restore and disaster recovery are tested through periodic drills, not just documented.
• On-call follows a disciplined flow and closes the loop with a postmortem.

In episode 20 we enter the more fun part: advanced use cases & design patterns — end-to-end automation for marketing, sales, operations, and IT, event-driven orchestration, approval workflows, up to chatbot, AI, and RPA integration. See you there!