n8n High Availability: Reference Architecture, Deployment Patterns, and Best Practices

Was „High Availability“ bei n8n wirklich bedeutet (und was nicht)

99,9% Verfügbarkeit heißt: 43 Minuten Ausfall pro Monat. Und ein Webhook-Spike interessiert sich nicht für dein Rolling Update.

Incident, 02:13 Uhr.

Ein Partner feuert 1.200 Webhooks/min. Gleichzeitig rotiert Kubernetes zwei Pods, weil ein Image gepusht wurde. Der Load Balancer (LB) verteilt fröhlich weiter, aber ein Pod ist gerade nicht Readiness Probe-ready, der andere hängt in einem langen Node-Drain ohne PodDisruptionBudget (PDB). Ergebnis: 2–3% Events fehlen. Nicht „später“.

Das ist der Moment, in dem „zwei Pods laufen“ als Konzept stirbt.

High Availability (HA) ist ein Betriebsziel: Der Service läuft trotz Ausfall einzelner Komponenten weiter. Skalierung ist Durchsatz. Disaster Recovery ist Wiederanlauf nach Totalschaden. Drei verschiedene Probleme. Drei verschiedene Messgrößen.

Messbar wird es über SLOs und RPO/RTO. Beispielwerte, die in der Praxis Sinn machen: Bei internen Automationen (nice-to-have) sind RPO 1–4h und RTO 1–2h oft akzeptabel. Bei revenue-kritischen Webhooks: RPO 0–1min, RTO 5–15min.

Bei Compliance/FinTech-Workflows: RPO nahe 0, RTO unter 5min — und dann reden wir über Multi-AZ, nicht über „mehr Pods“.

Unterstützt n8n High Availability und wie funktioniert das technisch? Aber nicht als magischer Schalter. HA entsteht in n8n durch Queue Mode: n8n Main und/oder Webhook Receiver nehmen UI/API/Webhooks an, persistieren Zustände, und legen Jobs in Redis. Worker ziehen aus der Queue und führen aus.

Horizontal. Event-Driven. Mit kontrollierter Retry-Strategie.

Die Single Points of Failure sind n8n-spezifisch und gnadenlos: PostgreSQL (Workflows, Executions, Credential-Metadaten), Redis (Queue/Backpressure/Retry), Encryption Key (N8N_ENCRYPTION_KEY) (ohne ihn sind Credentials praktisch tot), Binary Data (Attachments), plus Webhook-Registrierung/Ingress (LB-Timeouts, Sticky Sessions, falsche Health Checks).

„Kein Datenverlust“ muss definiert werden. Für n8n heißt das: keine verlorenen Webhook-Events (Annahme und Persistenz), keine fehlenden Executions (inkl. Status/Retry-Trace), keine unlesbaren Credentials (Encryption Key stabil), keine fehlenden Binary Data (shared Storage/Object Storage).

Alles andere ist Wortakrobatik.

Use-Case	„Robust“ (Single-Node) reicht, wenn…	Multi-Node/Multi-AZ nötig, wenn…
Interne Tools	Ausfall tolerierbar, Replays möglich, RPO Stunden	Webhook-Verlust ist kritisch, RTO < 30min
Partner-Webhooks	Provider kann sicher retryen, Idempotenz sauber	At-least-once nötig, Spike-Handling, RPO < 1min
Regulatorisch	—	Audit, DR-Tests, Multi-AZ-DB/Redis/Storage, RPO≈0

# n8n Queue Mode: Main nur UI/API/Webhooks, Worker macht Ausführung
export EXECUTIONS_MODE=queue
export QUEUE_BULL_REDIS_HOST=redis
export DB_TYPE=postgresdb
export DB_POSTGRESDB_HOST=postgres

# Kritisch: Encryption Key muss identisch auf allen Instanzen sein
export N8N_ENCRYPTION_KEY="32+bytes-stabil-aus-secret-store"

# Webhook Receiver separat betreiben (typisch: eigener Deployment)
# und hinter einem LB mit konservativen Timeouts
export N8N_ENDPOINT_WEBHOOK=/webhook
export N8N_DISABLE_UI=true

# Binary Data HA: nicht lokal im Pod-Dateisystem
export N8N_BINARY_DATA_MODE=s3
export N8N_BINARY_DATA_S3_BUCKET=n8n-binary-prod

Referenzarchitektur: Trennung von Webhook/Editor, Worker, Redis, Postgres und Storage

Welche Teile müssen wirklich zustandslos sein, damit Rolling Updates nicht weh tun? Die Kante. Also alles, was Traffic annimmt: Load Balancer (LB) und Webhook Receiver (plus n8n Main für UI/API), während Ausführung, Queue und Persistenz strikt entkoppelt laufen.

Blueprint. Ohne Ausreden.

LB/Ingress → Webhook Receiver/UI/API → Redis → Worker → PostgreSQL + Binary Data. Der LB terminiert TLS. Intern läuft mTLS oder mindestens TLS-verschlüsselt weiter, je nach Plattform. Der Webhook Receiver nimmt Requests an, schreibt minimalen Zustand (Request-Metadaten, dedupe keys) in PostgreSQL oder queued den Job in Redis, und ist danach fertig. Der Worker zieht aus der Queue, führt aus, persistiert Executions in Postgres und legt Binary Data in einen geteilten Store (NFS/CSI) oder besser Object Storage ab.

Kein lokales Pod-Filesystem.

Warum so hart getrennt?

Failure Domains. Skalierbarkeit. Backpressure. Und weil du sonst bei jedem Deploy die Hälfte deiner Webhooks verlierst.

• Webhook Receiver: zustandslos, horizontal, kurze Timeouts, klare Retry-Strategie.
• Redis: Queue/Coordination-Layer im Queue Mode, kritisch für Latenz und Retries.
• Worker: CPU/RAM-lastig, horizontal skalierbar, keine eingehenden Requests.
• PostgreSQL: Quelle der Wahrheit; Connection-Limits planen, Pooling erzwingen.
• Binary Data: shared/external; sonst ist HA nur ein Wort.

Netzwerk und Security-Schnitt. Streng.

TLS-Terminierung am Ingress, dann NetworkPolicies: Webhook Receiver darf zu Redis und Postgres. Worker darf zu Redis, Postgres, Binary Data Store. UI/API (n8n Main) darf zu Postgres und ggf. Redis (für Queue-Status), aber nicht zu externen Webhook-Paths. RBAC: getrennte ServiceAccounts für Receiver, Worker, Main.

Secrets: N8N_ENCRYPTION_KEY als Kubernetes Secret, versioniert nur via External Secrets/Vault, niemals in ConfigMaps. Rotation?

Nur geplant, sonst sind Credentials unlesbar. Punkt.

# n8n Queue Mode (Receiver/Main + Worker getrennt)
N8N_EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
N8N_ENCRYPTION_KEY=... (Secret)

Webhooks in HA: Load Balancer, Sticky Sessions, Registrierung. Was tun?

Sticky Sessions sind ein Pflaster.

Vermeide sie, wenn möglich. Der Webhook Receiver muss stateless sein, weil Webhooks sonst an „den falschen Pod“ gehen, sobald ein Rolling Update Pods ersetzt. Stattdessen: ein stabiler externer Webhook-Endpoint (LB/Ingress), kurze LB-Timeouts passend zur Upstream-Quelle, und serverseitig idempotente Verarbeitung. Für Quellen mit aggressiven Retries: 2xx schnell zurückgeben, dann asynchron über Redis ausführen. Für Quellen ohne Retries: Persistiere den Eingang zuerst (Postgres), dann ack.

# Ingress/LB: Timeouts so setzen, dass Webhook-Quellen nicht unnötig retryn
# Beispielwerte (plattformabhängig):
proxy_read_timeout 10s;
proxy_send_timeout 10s;

Webhook-Registrierung: n8n registriert Webhooks über die UI/API.

In HA darf das nicht an einen zufälligen Pod gebunden sein. Lösung: n8n Main als UI/API hinter dem LB, aber mit Readiness Probe, die erst „ready“ meldet, wenn DB erreichbar ist und Migrationen durch sind. Webhook Receiver kann identisch konfiguriert sein, aber ohne Editor-Traffic. Oder getrennte Deployments mit gleichem Base-URL-Setup.

# Kubernetes: Readiness/Liveness als Gate gegen kaputte Pods
readinessProbe:
  httpGet: { path: /healthz, port: 5678 }
  periodSeconds: 5
livenessProbe:
  periodSeconds: 10

Failure-Mode-Map. Kurz und brutal.

Ausfall	Was passiert	Was muss greifen
(a) ein Worker	Jobs bleiben in Redis, werden von anderen Workern gezogen; Durchsatz sinkt.	Horizontal Autoscaling, PDB, Anti-Affinity.
(b) Redis	Queue Mode steht. Webhooks können angenommen, aber nicht verteilt werden; Backpressure eskaliert.	Redis HA (Sentinel/Cluster/managed), Persistenz/Appendonly, klare Degradation-Policy.
(c) PostgreSQL	Alles hängt: Workflows, Executions, Credentials. UI und Worker werden instabil.	Managed HA, Connection-Pooling, Failover getestet, RPO/RTO definiert.
(d) eine Zone	Teilkapazität weg. Wenn Receiver/Worker/Redis/DB nicht zonenredundant sind: Totalausfall.	Anti-Affinity über Zonen, Multi-AZ für Redis/Postgres/Storage, PDB.

# Beispiel: NetworkPolicy-Idee (pseudocode)
# receiver -> allow egress to redis:6379, postgres:5432
# worker   -> allow egress to redis:6379,


  
Implementation Checklist
  

    
– Requirements definiert
    
– Architektur geplant
    
– Tests geschrieben
    
– Dokumentation erstellt
  

 postgres:5432, objectstore:443

Wenn du Governance und Betriebsprozesse dazu sauber aufziehst, wird aus „läuft“ ein System. Mehr dazu: n8n-Automatisierung in Unternehmensumgebungen (Integrationen, Betrieb, Governance).

Hätte man wissen können.

Lauffähige Setups: Docker Compose (Single-Host) vs. Kubernetes (echtes HA)

Wir haben n8n „HA“ genannt, obwohl alles auf einem Host lief. Falsch.

Docker Compose ist gut für Durchsatz-Tests, Queue Mode, Backpressure-Verhalten und operative Disziplin. Nicht für High Availability (HA). Ein Kernel-Panic, ein Storage-Glitch, ein Host-Reboot. Alles weg. Trotzdem: Als Blaupause für Entkopplung taugt es.

services:
  redis:
    image: redis:7-alpine
    command: ["redis-server","--appendonly","yes"]
    healthcheck:
      test: ["CMD","redis-cli","ping"]
      interval: 5s
      timeout: 2s
      retries: 20

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: n8n
    healthcheck:
      test: ["CMD-SHELL","pg_isready -U n8n -d n8n"]
      interval: 5s
      timeout: 3s
      retries: 20
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n-web:
    image: n8nio/n8n:latest
    depends_on:
      redis:
        condition: service_healthy
      postgres:
    ports: ["5678:5678"]
    environment:
      N8N_ENCRYPTION_KEY: "${N8N_ENCRYPTION_KEY}"
      DB_TYPE: "postgresdb"
      DB_POSTGRESDB_HOST: "postgres" # alternativ extern
      DB_POSTGRESDB_DATABASE: "n8n"
      DB_POSTGRESDB_USER: "n8n"
      DB_POSTGRESDB_PASSWORD: "n8n"
      EXECUTIONS_MODE: "queue"
      QUEUE_BULL_REDIS_HOST: "redis"
      QUEUE_BULL_REDIS_PORT: "6379"
      N8N_HOST: "n8n.example.com"
      N8N_PROTOCOL: "https"
      WEBHOOK_URL: "https://n8n.example.com/"
      N8N_EDITOR_BASE_URL: "https://n8n.example.com/"
    healthcheck:
      test: ["CMD-SHELL","wget -qO- http://localhost:5678/healthz || exit 1"]
      interval: 10s
      timeout: 3s
      retries: 15

  n8n-worker:
    command: ["n8n","worker"]
    depends_on:
      redis:
      postgres:
    environment:
      DB_POSTGRESDB_HOST: "postgres"
    healthcheck:
      test: ["CMD-SHELL","node -e \"process.exit(0)\""]
      interval: 30s
      timeout: 3s
      retries: 3

volumes:
  pgdata:

Dieses Compose-Setup ist bewusst nicht HA.

Ein Redis ohne Sentinel/Cluster. Ein PostgreSQL ohne Failover. Binary Data lokal, wenn du es nicht explizit auslagerst. Das funktioniert. Punkt.

Queue Mode trennt n8n Main von Worker. Das ist die zentrale Architekturentscheidung. Der Web-Prozess skaliert für Webhook Receiver und UI/API. Worker skaliert für Throughput. Backpressure entsteht in Redis, nicht im Load Balancer (LB).

Der Encryption Key (N8N_ENCRYPTION_KEY) ist nicht „nur ein Secret“. Rotierst du ihn falsch, brichst du Credential-Entschlüsselung. Sofort. Workflows laufen dann zwar noch, aber Nodes mit Credentials scheitern. Rotation nur als geplanter Migrationsschritt: neuer Key, Re-Encrypt in DB, dann Rollout. Kein „mal schnell im Secret ändern“.

Kubernetes schließt die Lücken: getrennte Deployments, Anti-Affinity über Nodes/Zonen, PodDisruptionBudget (PDB), Readiness Probe, Liveness Probe, HPA. Und ein LB/Ingress, der Webhook-Pfade korrekt behandelt.

# values.yaml (Helm-ähnlich, gekürzt)
web:
  replicaCount: 2
  extraEnv:
    - name: EXECUTIONS_MODE
      value: queue
    - name: N8N_ENCRYPTION_KEY
      valueFrom: {secretKeyRef: {name: n8n-secrets, key: encryptionKey}}
    - name: DB_POSTGRESDB_HOST
      valueFrom: {secretKeyRef: {name: n8n-secrets, key: pgHost}}
    - name: QUEUE_BULL_REDIS_HOST
      valueFrom: {secretKeyRef: {name: n8n-secrets, key: redisHost}}
  readinessProbe:
    httpGet: {path: /healthz, port: 5678}
    periodSeconds: 5
    failureThreshold: 6
  livenessProbe:
    periodSeconds: 10
    failureThreshold: 3

worker:
  replicaCount: 2
  autoscaling:
    enabled: true
    minReplicas: 2
    maxReplicas: 20
    targetCPUUtilizationPercentage: 70
  extraEnv:
      value: queue

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "25m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "30"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "30"
    nginx.ingress.kubernetes.io/keep-alive: "75"
  hosts:
    - host: n8n.example.com
      paths:
        - path: /
          pathType: Prefix

Wie setze ich n8n HA mit Kubernetes/Helm um (Ingress, Autoscaling, PDB)? Genau so: Web/Receiver replizieren, Worker per HPA skalieren, PDB erzwingt Mindestverfügbarkeit, Ingress-Timeouts passen zu Webhook-Quellen.

Ingress-Details sind kein Feintuning. Webhook-Pfade müssen sauber durchgehen. /webhook und /webhook-test sind nur Pfade; entscheidend sind Timeout, max body size, Keep-Alives.

Zu kurze Timeouts erzeugen Retries. Zu lange Timeouts binden Worker-Threads indirekt über offene Verbindungen. Idempotenz bleibt Pflicht.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: n8n-web-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: n8n-web

PDB verhindert, dass ein Node-Drain beide Web-Pods gleichzeitig entfernt. Ohne PDB ist „HA“ nur Hoffnung.

Aber funktioniert das wirklich?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n-web
spec:
  replicas: 2
  selector:
    matchLabels: {app: n8n-web}
  template:
    metadata:
      labels: {app: n8n-web}
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
              topologyKey: "kubernetes.io/hostname"

Anti-Affinity verteilt Pods. Sonst liegen beide auf einem Node. Dann ist dein LB nur Kosmetik.

Binary Data gehört nicht in Pod-Filesysteme. Nimm Object Storage oder geteilten Storage. Sonst verlierst du Payloads bei Reschedules, und Retries werden zur Datenkorruption.

Secrets: DB/Redis URLs und N8N_ENCRYPTION_KEY in Kubernetes Secrets. Rotation: Redis/DB-Passwörter gehen mit Dual-Write nicht; plane Wartungsfenster. Encryption Key nur mit Re-Encrypt (kein Scherz).

Alles andere bricht hart.

Architektur-Prinzipien für produktive Deployments mit sensiblen Daten

Sizing, Performance und Kosten: Worker-Throughput, Redis/Postgres Limits, Backpressure

Man erwartet: mehr Pods rein, alles wird linear schneller. Realität: PostgreSQL limitiert zuerst, dann Redis, dann erst CPU.

Fair enough.

Die schiefe Architekturentscheidung: n8n Main im Non-Queue-Mode skaliert, weil „mehr Instanzen = mehr Durchsatz“. Das Ergebnis war Chaos. Webhooks doppelt, Executions kollidierten, Latenz sprang, und niemand verstand Backpressure.

Für High Availability (HA) brauchst du Redis und PostgreSQL. Punkt. Queue Mode ohne Redis existiert nicht, und ohne PostgreSQL fehlt dir die primäre Persistenz. Empfohlen: PostgreSQL 14–16, Redis 6/7. Nimm stabile Minor-Releases, keine Exoten-Builds.

Und genau da liegt das Problem.

Komponente	Start-Sizing (Richtwert)	Skalierungssignal
n8n Main (UI/API)	1 vCPU / 1–2 GB RAM je Pod	HTTP-Latenz, 5xx, CPU-Throttle
Webhook Receiver	0,5–1 vCPU / 512 MB–1 GB RAM je Pod	Webhook-Spikes, LB-Timeouts, Queue-Länge
Worker	1–2 vCPU / 2–4 GB RAM je Pod	Queue-Länge, Job-Runtime, Retry-Rate

Startpunkt für Worker-Anzahl: 2–4 Worker pro Umgebung. Dann messen. Dann verdoppeln.

Concurrency ist dein Hebel, aber auch dein Sprengsatz. Pro Worker starte mit 5–10 gleichzeitigen Jobs, wenn die Workflows I/O-lastig sind; bei CPU-lastigen Nodes eher 2–4. Idempotenz entscheidet, ob Retries dich retten oder Daten duplizieren.

Queue-Länge ist ein Frühwarnsystem. Steigt sie dauerhaft, fehlt Durchsatz. Steigt sie nur bei Spikes, fehlt Burst-Kapazität oder Webhook Receiver puffert zu wenig.

# Queue Mode aktivieren (Kern für HA)
EXECUTIONS_MODE=queue
# Worker-Concurrency (Startwert, dann messen)
N8N_CONCURRENCY=8

PostgreSQL kippt selten „plötzlich“. Es kündigt sich an: steigende Query-Latenz, Connection-Errors, Autovacuum-Lag, dann Timeouts.

Connection-Limits sind hart. Rechne grob: pro n8n-Prozess 5–20 Verbindungen, je nach Features und Last. 10 Pods mit je 15 Verbindungen sprengen ein max_connections=100 sofort.

# pgbouncer als Pflicht bei vielen Pods
# Ziel: wenige DB-Verbindungen, viele App-Sessions
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20

Indizes und Autovacuum sind Betriebspflicht. Nicht optional. Wenn Executions-Tabellen wachsen, brauchst du Wartungsfenster, Vacuum-Tuning und Monitoring auf Bloat.

Redis: Für Queue Mode kritisch wegen Latenz und Retry-Handling. Für HA: Sentinel, Cluster, oder Managed. Self-hosted ohne Failover ist kein HA, nur Hoffnung.

# Redis-Timeouts: zu aggressiv => „stuck jobs“, zu lax => lange Hänger
QUEUE_BULL_REDIS_TIMEOUT_THRESHOLD=10000
QUEUE_HEALTH_CHECK_ACTIVE=true

„Stuck jobs“ entstehen oft durch Netzwerk-Flaps oder zu kurze Redis-Timeouts bei hoher Latenz. Dann laufen Worker weiter, aber die Queue-ACKs fehlen. Ergebnis: Retries, Duplikate, Backpressure bis zum Stillstand.

# PostgreSQL: konservative Defaults, dann gezielt anheben
# (Beispielwerte; an Workload und RAM anpassen)
shared_buffers=25% RAM
effective_cache_size=75% RAM

Kostenrahmen: Managed PostgreSQL/Redis kostet mehr pro Stunde, spart aber AZ-HA, Backups, Patching, Pager-Duty. Self-hosted kostet weniger Cloud-Rechnung, frisst aber Ops-Zeit und verlangt saubere Runbooks.

• Managed, wenn du Multi-AZ, RPO/RTO, Backups und Upgrades ohne eigenes DBA willst.
• Self-hosted, wenn du 24/7 Ops abdecken kannst und Failure-Tests wirklich fährst.
• Hybrid ist oft sinnvoll: Managed PostgreSQL, Redis managed oder Sentinel mit klaren SLOs.
• Entscheide nach Connection-Limits, Failover-Zeit, Backup-Restore-Drills, nicht nach Listenpreis.

Wenn du Automatisierung plus AI-Workloads planst, brauchst du ein sauberes Betriebsmodell. Siehe Vorgehen, um Automatisierung/AI-Workloads sauber in Betrieb zu bringen (inkl. Stolpersteine).

Betrieb, Troubleshooting und DR: Runbooks für die häufigsten HA-Failure-Modes

ERROR 2026-02-28T10:14:22.981Z [Queue] BullMQ: Missing lock for job 8f3c... moveToFinished
WARN  2026-02-28T10:14:23.004Z [Redis] Connection lost (ECONNRESET), retrying in 5000ms

Pager. 03:17. Kein Kontext.

In n8n HA kommen die gleichen Failure-Modes wieder. Stuck executions, Redis-Disconnects, DB-Locks/Connection-Exhaustion, Duplicate Webhooks. Das ist kein Zufall, sondern ein Schnitt durch die Bounded Contexts: Queue (Redis), Persistenz (PostgreSQL/Binary Data), Ingress (Load Balancer), Ausführung (Worker). Event-Driven Systeme verzeihen keine Latenz-Spikes ohne Backpressure.

Signal	Warum es zählt	Alert-Schwelle (Startpunkt)
Queue depth (Redis/BullMQ)	Backpressure sichtbar machen	> 1.000 für 5 min
Execution latency p95	Skalierbarkeit/DB/Redis-Latenz	> 60s für 10 min
Error rate (5xx / workflow errors)	Ingress/Worker/Dependencies	> 2% für 5 min

Health-Endpunkte sind Pflicht. Punkt. Für n8n Main und Webhook Receiver getrennt, damit eine kaputte UI nicht Webhooks frisst. Readiness Probe auf „kann DB+Redis erreichen“. Liveness Probe auf „Eventloop lebt“; sonst killst du Pods bei transienter DB-Latenz.

Runbook: stuck executions
Symptome: Executions hängen in „running“, Queue depth steigt, Worker-Logs zeigen Lock/ACK-Probleme.

Okay.

Diagnose: Redis-Latenz und Worker-Throughput prüfen, dann hängende Executions identifizieren. Fix: Worker kontrolliert neu starten, Jobs re-queue’n, notfalls Executions abbrechen. Prävention: Timeouts/Retry-Policy konsistent, Worker-Anti-Affinity, Redis mit stabilen Node-Pools.

# Beispiele: Diagnose stuck executions
kubectl logs deploy/n8n-worker -n n8n --since=30m | egrep "Missing lock|stalled|ECONNRESET"
redis-cli -h $REDIS_HOST -p 6379 ping
psql "$DATABASE_URL" -c "select id,status,startedAt from execution_entity where status='running' order by startedAt asc limit 20;"

Runbook: Redis disconnects/timeouts
Symptome: „ECONNRESET“, „ETIMEDOUT“, plötzliche Retry-Stürme, Duplicate Webhooks nach Retries. Diagnose: Redis-Events und Netzwerk. Prüfe, ob Node-Rotation oder Security-Policy die TCP-Sessions kappt. Fix: Redis-Client-Timeouts hoch, TCP keepalive aktivieren, Worker-Pods neu schedulen. Prävention: Managed Redis mit Multi-AZ, PodDisruptionBudget (PDB) für Worker, Load Balancer Idle-Timeout sauber setzen, damit Webhook Receiver nicht mitten im Request abgeräumt wird.

Runbook: DB locks / connection exhaustion (PostgreSQL)
Symptome: UI/API langsam, Webhook Receiver nimmt an, aber Persistenz blockiert; Logs: „too many clients already“, „deadlock detected“, „canceling statement due to lock timeout“. Diagnose: aktive Locks und Connection Count.

Fix: Connection-Pool begrenzen (nicht jeder Pod 50 Verbindungen), stuck Queries killen, Migrationsfenster kontrollieren. Prävention: Postgres Connection-Limits planen, pgbouncer, Indexe auf Execution-Tabellen, Upgrade-Migrations vorher in Staging mit Produktionsdatenvolumen testen.

# Diagnose DB-Locks/Connections
psql "$DATABASE_URL" -c "select count(*) from pg_stat_activity;"
psql "$DATABASE_URL" -c "select pid,wait_event_type,wait_event,query from pg_stat_activity where wait_event_type is not null;"
psql "$DATABASE_URL" -c "select blocked_locks.pid as blocked_pid, blocking_locks.pid as blocking_pid
from pg_locks blocked_locks join pg_locks blocking_locks
on blocked_locks.locktype=blocking_locks.locktype and blocked_locks.database is not distinct from blocking_locks.database
and blocked_locks.relation is not distinct from blocking_locks.relation
where not blocked_locks.granted and blocking_locks.granted;"

Runbook: duplicate webhooks
Symptome: Doppelte Side-Effects (z.B.

zwei Tickets), obwohl nur ein Event gesendet wurde. Diagnose: Load Balancer Retries, Client Retries, Webhook Receiver Timeouts, fehlende Idempotency. Fix: Idempotency-Key in Workflow erzwingen (z.B. dedupe via Postgres-Unique-Key oder Redis SETNX), LB-Retry für POST aus, Timeout-Kette prüfen (Client < LB < Ingress < Webhook Receiver). Prävention: Webhook Receiver getrennt skalieren, eindeutige Request-IDs loggen, 202 Accepted nutzen, wenn Verarbeitung async ist und Persistenz garantiert ist.

Monitoring/Alerting: Logs sind nicht genug. Du brauchst Metriken pro Komponente.

Überraschung.

Queue depth, execution latency, error rates. Und ein Alert, der nicht lügt: „Queue depth > 1.000“ ohne Kontext ist Krach; „Queue depth > 1.000 und Worker CPU < 40%“ zeigt, dass du blockierst, nicht skalierst.

Backup/Restore, wirklich konsistent
PostgreSQL-Backup.

Binary Data. Und der Encryption Key (N8N_ENCRYPTION_KEY). Wenn der Key fehlt, sind Credentials Müll. Das ist kein „nice to have“.

# Konsistentes Postgres-Backup (Beispiel)
pg_dump --format=custom --no-owner --file n8n.pg.dump "$DATABASE_URL"
# Binary Data (Beispiel: S3 Prefix)
aws s3 sync s3://$BINARY_BUCKET/n8n/ ./binary-data/
# Encryption Key separat sichern (Secret-Export, stark geschützt)
kubectl get secret n8n-secrets -n n8n -o yaml > n8n-secrets.backup.yaml

Restore-Drill: In isolierter Umgebung wiederherstellen. n8n Main starten. Ein Workflow mit Credential-Zugriff muss laufen. Dann RPO/RTO messen: Wie alt ist das Dump? Wie lange bis „Webhook Receiver ready“? Zahlen notieren. Runbook aktualisieren. Kein Theater.

Nicht vergessen: Immer erst in Staging testen. Immer.

Anmerkung: Die hier gezeigte Konfiguration stammt aus einem realen Setup – nicht aus der Doku kopiert.

Kurze Pause.

Upgrade-Strategie
Rolling ist okay, wenn DB-Migrationen rückwärtskompatibel sind. Sind sie es nicht, brauchst du Blue/Green. Migrations-Fallen: lange Locks auf großen Tabellen, neue Indizes ohne CONCURRENTLY, Redis-Kompatibilität (BullMQ/Redis-Version), Postgres-Parameter (max_connections, statement_timeout). Checkliste vor Deploy: DB-Backup vorhanden und verifiziert, N8N_ENCRYPTION_KEY verfügbar, Binary Data erreichbar, Readiness Probe testet DB+Redis, PDB aktiv, Anti-Affinity für Worker, LB-Timeouts geprüft.

Wenn du dafür keine Zeit hast, kaufst du sie ein. AI Automation.