Introduzione

Se ultimamente le tue automazioni si sono “piantate” senza un motivo chiaro, sappi che non sei solo: nelle versioni 1.105.x–1.111.x diversi utenti hanno segnalato esecuzioni che da secondi passano a minuti, UI meno reattiva, errori 503 e perfino crash dovuti a memoria. Questo articolo è un playbook pratico di n8n troubleshooting performance pensato per chi usa n8n per lavorare meglio, non per passare ore nella diagnostica. In 15 minuti capirai come riconoscere i pattern di degrado, impostare una diagnosi end-to-end senza perdere produzione, profilare memoria e CPU con flamegraph e heap snapshot in V8, evitare lock e deadlock in Postgres, e gestire backpressure e concorrenza in modo elegante. Copriremo anche tuning di retention degli storici ed esecuzioni, limiti memoria Docker e garbage collector V8, e le best practice per grandi volumi di dati nei nodi n8n. Obiettivo: farti tornare alla produttività con un flusso stabile, misurabile e ottimizzato.

Cosa sta succedendo davvero: sintomi ricorrenti e quando preoccuparsi

Negli ultimi mesi la community ha riportato problemi di prestazioni concentrati su versioni 1.105.x–1.111.x: interfaccia lenta, esecuzioni più lunghe, errori 503, saturazione della memoria e difficoltà a consultare lo storico. Questi segnali spesso emergono su istanze Docker con Postgres, workflow con grandi volumi per nodo, pattern con Merge/Switch e loop, e scenari d’integrazione pesanti (HTTP, Microsoft/Outlook/Teams, NocoDB). Per un marketer, il problema è concreto: campagne che non si sincronizzano in tempo, lead che restano in coda, report che si aggiornano a singhiozzo.

Come distinguere un picco fisiologico da un problema strutturale:

• Se UI e canvas rallentano subito dopo esecuzioni “corpose”, sospetta un collo di bottiglia in memoria o nell’event loop.
• Se compaiono 503 e “Connection Lost”, verifica se l’istanza è diventata non disponibile per OOM o CPU al 100%.
• Se gli storici diventano il “nuovo collo di bottiglia”, rivedi retention e pruning.
• Se noti code crescenti e lavoratori che non smaltiscono, sei in backpressure.

Punto chiave: non affidarti al “feeling”. Implementa subito un percorso di diagnostica delle prestazioni di n8n con metriche, log e parametri controllati. Questo ti permette di correlare cambi versione/configurazione con i sintomi e accorciare il tempo di risoluzione.

Diagnosi end-to-end: metriche, log e baseline che contano

Prima di toccare qualsiasi impostazione, crea una baseline. Misura il tempo medio di esecuzione dei workflow critici, la stabilità del canvas, e gli errori in UI/API. Attiva log adeguati e segui questi passi:
1) Raccogli segnali di sistema

• CPU, RAM, I/O del container n8n e del database Postgres.
• Eventuali restart del container (spia di OOM).
• Latenza media dei webhook e throughput delle code.

2) Configura le variabili di esecuzione essenziali

• EXECUTIONSTIMEOUT ed EXECUTIONSTIMEOUT_MAX stabiliscono limiti di esecuzione per evitare run “zombie”.
• EXECUTIONSDATASAVEONERROR e EXECUTIONSDATASAVEONSUCCESS per ridurre il peso degli storici quando non servono tutti i dettagli.

3) Verifica l’event loop

• Se noti ritardi intermittenti, c’è probabilmente pressione sull’event loop. Un’analisi dell’event loop in ambienti n8n, con un profiler, ti dà evidenza di funzioni o nodi che bloccano.

4) Classifica i workflow per impatto

• Elenca quelli con maggior numero di item per nodo o con loop profondi. Sono candidati per batching e refactoring.

Insight unico: collega sempre i picchi di latenza nei webhook e i time-to-complete dei workflow alle campagne o ai lanci che stai gestendo. Una mappa “campagna → workflow → KPI tecnici” aiuta a prevenire problemi prima dei picchi di traffico.

Profiling Node.js in n8n: flamegraph e heap snapshot in V8

Per identificare memory leak o hot path CPU, usa strumenti standard di Node.js con n8n self-hosted.

Step-by-step (Docker):
1) Avvia n8n con il debugging e un tetto di memoria adeguato

• Imposta V8 e debugger:
• NODE_OPTIONS=”–inspect=0.0.0.0:9229 –max-old-space-size=4096″
• Esempio docker-compose (sezione environment):
• NODE_OPTIONS=–inspect=0.0.0.0:9229 –max-old-space-size=4096

2) Collega Chrome DevTools

• Apri chrome://inspect, aggiungi host:porta del container (es. 9229).
• Registra una CPU profile mentre esegui un workflow “problematico”.
• Cattura un heap snapshot per individuare oggetti che crescono nel tempo (flamegraph e heap snapshot in V8).

3) Interpreta i risultati

• CPU: se vedi funzioni di parsing, trasformazioni massive o loop sincroni in cima al flamegraph, valuta Split In Batches e trasformazioni puntuali (Set/Move) per ridurre payload intermedi.
• Memoria: oggetti che aumentano tra snapshot indicano leak. Verifica nodi che “accumulano” output inutilmente o cicli con dati non potati.

4) Rimedia subito

• Riduci payload ai soli campi necessari prima dei nodi più costosi.
• Evita concatenazioni di grandi array; usa batching.
• Se necessario, aumenta temporaneamente la memoria di V8 (limiti memoria Docker e garbage collector V8 con –max-old-space-size) mentre refattorizzi.

Parole chiave utili: profiling memoria Node.js per workflow n8n, analisi dell’event loop in ambienti n8n.

Tuning Postgres: evitare slow query, lock e deadlock

Il database può diventare il collo di bottiglia se retention, query o concorrenza non sono gestite.

1) Individua lock e deadlock

• Query operative:
• SELECT pid, waiteventtype, waitevent, state, query FROM pgstat_activity WHERE state <> ‘idle’;
• SELECT a.pid, l.locktype, l.mode, a.query FROM pglocks l JOIN pgstat_activity a ON a.pid = l.pid WHERE NOT granted;
• Se vedi sessioni bloccate, individua la query lunga che trattiene il lock e valuta di intervenire riducendo retention o pianificando pruning in orari off-peak.

2) Attiva slow query log

• Imposta logminduration_statement (es. 200ms) per catturare query lente.
• Esegui EXPLAIN ANALYZE sulle query lente (copiale dai log) per capire se servono indici aggiuntivi o cambi di pattern nei workflow (es. evitare filtri multipli ripetuti).

3) Parametri di base (linee guida)

• shared_buffers: ~25% RAM server.
• effectivecachesize: 50–75% RAM.
• work_mem: aumenta con cautela se hai molte sort/hash simultanee.
• max_connections: mantienilo in un range realistico, evita saturazione.

4) Routine di manutenzione

• Pruning regolare degli storici (vedi sezione successiva).
• Evita scansioni massicce generate da filtri ad hoc in reporting; sposta aggregazioni su strumenti esterni quando possibile.

Parole chiave: tuning Postgres per esecuzioni n8n, lock e deadlock su pgstatactivity, slow query e EXPLAIN ANALYZE per n8n.

Backpressure e concorrenza: Queue mode, Redis e limiti di esecuzione

Se il carico supera la capacità, gestisci esplicitamente la concorrenza.

1) Abilita Queue mode

• Variabile: EXECUTIONS_MODE=queue
• Redis:
• QUEUEBULLREDIS_HOST=localhost
• QUEUEBULLREDIS_PORT=6379
• Avvia worker separati e configura webhook processor se serve scalare gli ingressi.

2) Imposta limiti di concorrenza

• In queue mode, controlla i job per worker via flag –concurrency.
• Limite globale self-hosted: N8NCONCURRENCYPRODUCTION_LIMIT (valore > -1 per attivarlo).
• Monitora i log: esecuzioni aggiunte in coda e rilasciate indicano backpressure e smaltimento.

3) Segmenta workload

• Separare workflow ad alto throughput su worker dedicati.
• Pianifica campagne e import/batch in finestre orarie diverse.

Parole chiave: backpressure e code di lavoro in n8n, concorrenza delle esecuzioni e impostazioni worker.

Retention, pruning e storici: riduci il peso senza perdere controllo

Storici troppo “ricchi” rallentano DB e UI. Configura le variabili dedicate:

• EXECUTIONSDATASAVEONERROR=all|none (default all)
• EXECUTIONSDATASAVEONSUCCESS=all|none (default all)
• EXECUTIONSDATASAVEONPROGRESS=true|false (default false)
• EXECUTIONSDATASAVEMANUALEXECUTIONS=true|false (default true)
• EXECUTIONSDATAPRUNE=true|false (default true)
• EXECUTIONSDATAMAX_AGE=336 (ore; default 14 giorni)
• EXECUTIONSDATAPRUNEMAXCOUNT=10000 (0 = illimitato)
• EXECUTIONSTIMEOUT, EXECUTIONSTIMEOUT_MAX per interrompere esecuzioni troppo lunghe

Esempio docker-compose (estratto):

• EXECUTIONS_MODE=queue
• QUEUEBULLREDIS_HOST=redis
• QUEUEBULLREDIS_PORT=6379
• EXECUTIONSDATASAVEONSUCCESS=none
• EXECUTIONSDATASAVEONERROR=all
• EXECUTIONSDATAPRUNE=true
• EXECUTIONSDATAMAX_AGE=168
• EXECUTIONSDATAPRUNEMAXCOUNT=5000
• EXECUTIONS_TIMEOUT=1800
• EXECUTIONSTIMEOUTMAX=3600
• NODE_OPTIONS=–max-old-space-size=4096

Suggerimento: se usi SQLite in dev, lo spazio non si libera immediatamente con il prune ma viene riutilizzato; con Postgres tieni d’occhio dimensione e vacuum.

Parole chiave: retention degli storici ed esecuzioni in n8n.

Best practice per grandi volumi di dati nei nodi n8n

Quando un nodo processa migliaia di item, i colli di bottiglia emergono presto. Ecco come evitarli:

• Split In Batches: spezza dataset in chunk gestibili e serializza i passi più pesanti.
• Riduci il payload: usa Set/Move per mantenere solo i campi necessari prima di chiamate HTTP o merge.
• Minimizza anteprime e dati non necessari: durante lo sviluppo puoi vedere tutto; in produzione punta all’essenziale.
• Evita loop profondi con trasformazioni sincrone pesanti; sposta calcoli complessi a servizi dedicati o funzioni serverless.
• Valuta storage esterni per binari pesanti; mantieni il DB “snello”.
• Pianifica retry e backoff intelligenti: la gestione errori efficace riduce rielaborazioni massicce.

Risultato: workflow più stabili e veloci, meno memory spike e un carico prevedibile. Parole chiave: best practice per grandi volumi di dati nei nodi n8n.

Playbook di rollback/canary e verifica dei fix

• Canary release: aggiorna 1 worker o 1 progetto alla volta, confronta KPI di esecuzione e errori con il gruppo di controllo.
• Rollback rapido: mantieni le versioni Docker precedenti pronte al deploy.
• Test mirati: ricarica i dati di un’esecuzione fallita nell’editor (Debug/Copy to editor) per validare fix senza rischi.
• Osservabilità: mantieni un cruscotto con tempi di esecuzione, errori, code e utilizzo RAM/CPU per vedere effetti dei cambi subito.

Insight: collega i tuoi KPI marketing (lead elaborati/ora, tempi di sync CRM, tempi di invio) ai KPI tecnici. Quando ottimizzi, verifica sempre l’effetto sul risultato di business.

Quick Takeaways

• Metti in sicurezza la diagnostica: baseline, log e profiler prima di cambiare impostazioni.
• Usa flamegraph e heap snapshot per trovare hot path e memory leak reali.
• Abilita Queue mode e limita la concorrenza per gestire backpressure.
• Tieni sotto controllo Postgres con pgstatactivity, pg_locks e slow query log.
• Configura retention e pruning con EXECUTIONSDATA* per evitare DB pesante e UI lenta.
• Per grandi volumi, applica batching e riduci il payload fra i nodi.
• Pianifica canary/rollback per aggiornamenti sicuri e misurabili.

Conclusione

n8n è straordinariamente flessibile, ma proprio questa libertà può portare a colli di bottiglia se non metti in campo una metodologia solida. Con il playbook che hai appena letto puoi affrontare n8n troubleshooting performance in modo professionale: diagnosi mirata, profiling memoria e CPU, lettura dei segnali del database, gestione della concorrenza e backpressure, e una policy di retention snella. Per un marketer, tutto questo si traduce in automazioni più affidabili e campagne che girano puntuali, senza sorprese all’ultimo miglio. Fai piccoli passi: abilita Queue mode, limita la concorrenza, riduci lo storico agli insight davvero utili, spezza i dataset e monitora l’effetto sui KPI di business. Se vuoi portare le tue automazioni al livello successivo, crea ora una checklist di tuning da applicare ai tuoi 3 workflow più critici e misura il miglioramento già questa settimana.

FAQ

1) Come faccio la diagnostica delle prestazioni di n8n senza fermare la produzione?

• Imposta una baseline, attiva i log, usa EXECUTIONS_TIMEOUT per prevenire run infinite, e abilita Queue mode per isolare i worker. Poi esegui profiling memoria Node.js per workflow n8n su un ambiente di staging o su un worker canary.

2) Come analizzare l’event loop in ambienti n8n?

• Avvia n8n con NODE_OPTIONS=”–inspect=0.0.0.0:9229″ e usa Chrome DevTools per registrare CPU profile. Il flamegraph evidenzia funzioni bloccanti e ti guida nel refactoring di nodi e trasformazioni.

3) Quali variabili impostare per evitare storici troppo pesanti?

• Usa EXECUTIONSDATASAVEONSUCCESS=none quando non servono i dettagli dei successi, mantieni EXECUTIONSDATASAVEONERROR=all, imposta EXECUTIONSDATAPRUNE=true, EXECUTIONSDATAMAXAGE e EXECUTIONSDATAPRUNEMAX_COUNT per il pruning automatico.

4) Come rilevare lock e deadlock in Postgres legati a n8n?

• Interroga pgstatactivity e pglocks per vedere sessioni in attesa e lock non concessi. Attiva slow query log e usa EXPLAIN ANALYZE sulle query lente per ottimizzare. Parole chiave: lock e deadlock su pgstat_activity, slow query e EXPLAIN ANALYZE per n8n.

5) Come gestire backpressure e concorrenza delle esecuzioni e impostazioni worker?

• Abilita EXECUTIONSMODE=queue, configura Redis (QUEUEBULLREDISHOST/PORT) e limita la concorrenza con –concurrency e N8NCONCURRENCYPRODUCTION_LIMIT. Applica Split In Batches e riduci il payload per mantenere la coda fluida.

Hai trovato utile questa guida? Raccontaci nei commenti qual è stato il collo di bottiglia più subdolo che hai risolto e condividila con chi usa n8n in team: potrebbe far risparmiare ore di debug anche a loro!