Guida al nodo Wait di n8n: come mettere in pausa le tue automazioni

Hai mai desiderato stoppare un flusso, “aspettare” un momento preciso o un input esterno, e poi ripartire esattamente da lì? Il nodo wait n8n è lo strumento giusto: consente di mettere in pausa un workflow n8n e riprenderlo al verificarsi di una condizione temporale o di un evento, senza mantenere risorse in esecuzione e senza perdere lo stato. In questa guida pratica scoprirai come funziona il nodo Wait di n8n, quando preferirlo a Delay/Cron, e come configurare le quattro modalità di ripresa: After Time Interval, At Specified Time, On Webhook Call, On Form Submitted. Vedremo come usare $execution.resumeUrl n8n per attivare riprese via link o API, come impostare autenticazione JWT per webhook n8n, e come bilanciare risposta immediata al webhook in pausa con risposte “ultimo nodo” o “Respond to Webhook”. Chiuderemo con configurazione avanzata (whitelist IP e sicurezza del webhook, raw/binary body), limiti di attesa e timeout nel Wait node, più una galleria di esempi e template testati sul campo. Se sei un/una marketer, questa guida ti aiuterà a costruire follow‑up e reminder affidabili, approvazioni human‑in‑the‑loop e finestre di offerta “a tempo” senza scrivere codice.

📚 Nuovo a n8n? Parti dalla guida completa: cos’è n8n e come funziona.

[IMG: Panoramica di un workflow con Wait in modalità “On Webhook Call” e due possibili rami di ripresa]

Che cos’è il nodo Wait e quando usarlo

Il nodo Wait di n8n sospende l’esecuzione corrente e la “parcheggia” in modo sicuro fino al verificarsi di una condizione di ripresa. A differenza di soluzioni manuali (sleep in un Code node) o del solo Cron (che lancia nuovi run), il Wait:

mette “in pausa” un run specifico del workflow, mantenendo lo stato;
offloada l’esecuzione, evitando consumi eccessivi di risorse durante l’attesa;
riprende esattamente dal punto in cui è stato inserito, con i dati originali.

Quando sceglierlo rispetto a Delay/Cron:

Delay breve vs attese lunghe: per attese superiori a una manciata di secondi, il Wait è più robusto del “sleep”. Per follow‑up programmati o reminder, è la scelta naturale.
Cron lancia nuovi run: ottimo per processi ricorrenti; il Wait serve quando vuoi sospendere e poi riprendere la stessa automazione (es. campagna che attende una conferma).
Event‑driven: con “On Webhook Call” o “On Form Submitted”, il Wait lascia in sospeso finché arriva un evento esterno, ideale per riprese a fronte di approvazioni o input utente.

Esempi tipici per marketer:

mettere in pausa un workflow n8n per 24h e poi inviare un promemoria;
pianificare la ripresa a orario specifico per pubblicazioni time‑sensitive;
riprendere un’automazione tramite webhook quando un cliente conferma una prova/proposta;
usare un form integrato per raccogliere feedback e sbloccare il passaggio successivo.

[IMG: Schema di confronto tra Wait, Cron e “sleep” in Code node]

Modalità temporali di ripresa

Le modalità time‑based sono due: “After Time Interval” e “At Specified Time”. Entrambe sono pensate per programmare la ripresa del flusso in modo affidabile.

Dopo un intervallo di tempo

Use case: follow‑up, reminder, finestre di prova, cooldown tra step di nurturing.

Configurazione tipica:

Mode: After Time Interval
Wait Amount: quantità (es. 24)
Wait Unit: Seconds, Minutes, Hours, Days (es. Hours)
Note operative:
Per follow‑up in ore/giorni, preferisci Hours/Days per chiarezza.
Se devi scalare, evita decine di attese brevissime: meglio raggruppare logica o usare condizioni.

Esempio concreto:

Funnel lead magnet: invio primo contenuto → Wait (After Time Interval: 48 Hours) → check di engagement → invio secondo contenuto solo agli interessati.
KPI reminder: se non ricevi un certo evento (es. pagamento), Wait per 24h e poi notifica su Telegram/Slack.

Keyword integrate: intervallo di attesa programmato, esempi e template per automazioni n8n.

[IMG: Pannello Wait node, tab “After Time Interval” con Wait Amount=48, Wait Unit=Hours]

A un orario specifico e gestione del fuso orario

Use case: lanci, promozioni time‑boxed, report giornalieri alle 08:00.

Configurazione tipica:

Mode: At Specified Time
Date and Time: seleziona dal picker l’orario preciso di ripresa

Best practice sulla gestione del fuso orario in n8n:

Verifica il timezone del server/istanza: pianifica in UTC se collabori con team globali.
Se l’orario dipende dalla località utente, normalizza l’input a UTC e documenta la conversione.
Se possibile, evita orari borderline (es. cambio ora legale): usa buffer o check a valle per conferma.

Esempio:

Promo “flash” alle 18:00 locali: calcola l’ora UTC dalla località, imposta “At Specified Time”, poi pubblica su canali e social con nodi dedicati.

[IMG: Wait node con date‑time picker e nota “All times are UTC” nel canvas]

Ripresa su evento: webhook e form

Quando la ripresa dipende da un’azione dell’utente o un evento esterno, preferisci una modalità event‑driven: “On Webhook Call” o “On Form Submitted”.

$execution.resumeUrl, autenticazione e gestione della risposta

On Webhook Call crea un endpoint dedicato per “svegliare” l’esecuzione. Ogni run ha il suo URL di ripresa, accessibile come espressione.

Impostazioni chiave:

Mode: On Webhook Call
Authentication: None, Basic Auth, Header Auth, JWT
Basic Auth: definisci user/password.
Header Auth: richiedi un header statico (es. X-Resume-Key).
JWT: valida un token firmato lato n8n (autenticazione JWT per webhook n8n).
Respond: Immediately, When Last Node Finishes, Using “Respond to Webhook” Node

Come ottenere e usare l’URL:

In un nodo precedente (es. Telegram/Email), includi il link {{$execution.resumeUrl}} in un messaggio “Approva/Declina” o “Conferma”.
Un click o una chiamata HTTP al link riprende l’esecuzione.

Esempio curl (ripresa con payload JSON e header custom):

curl -X POST "$execution.resumeUrl" \
  -H "Content-Type: application/json" \
  -H "X-Resume-Key: your-secret" \
  -d '{"status":"approved","by":"@mario"}'

Gestione della risposta:

Respond: Immediately → il chiamante riceve subito 200 OK (ottimo per link cliccati da browser).
When Last Node Finishes → attende l’elaborazione e restituisce l’output finale.
Using “Respond to Webhook” Node → massimo controllo su status/body/header (inserisci un nodo “Respond to Webhook” a valle).

Keyword integrate: riprendere un’automazione tramite webhook, risposta immediata al webhook in pausa.

[IMG: Messaggio Telegram con pulsante che punta a {{$execution.resumeUrl}}]

Modulo form: scenari pratici e limitazioni

On Form Submitted consente di mostrare un form integrato per raccogliere input prima di riprendere l’esecuzione.

Use case:

Approvazioni con motivazione
Raccolta dati per arricchire un record (budget, scadenza, owner)
QA/feedback in campagne

Best practice:

Campi necessari e validazione lato form; evita input liberi se non indispensabili.
Prevenzione spam: usa Authentication o limita la condivisione del link di form.
UX: fornisci istruzioni concise e placeholder significativi.

Limitazioni operative:

Non usare per grandi volumi pubblici; per audience ampia meglio un “Form Trigger” dedicato.
Se servono allegati, valuta flussi con upload dedicato + ripresa via webhook.

[IMG: Anteprima form con campi “Esito (Approve/Reject)”, “Note”, “Deadline”]

Configurazione avanzata, limiti e sicurezza

Quando usi “On Webhook Call”, il Wait eredita opzioni avanzate simili a un endpoint webhook.

Sicurezza endpoint
Authentication: None/Basic/Header/JWT (scegli in base al rischio).
whitelist IP e sicurezza del webhook: limita a sorgenti note quando possibile.
Ignore Bots: evita trigger accidentali da crawler/bot.
Raw Body: conserva il body grezzo per verifiche (es. firme HMAC) o parsing custom.
Binary: accetta file binari se hai casi d’uso che richiedono allegati (raramente necessario nel resume).
Limiti di attesa e timeout nel Wait node
Attese brevi (<65s): in alcuni ambienti, attese molto brevi possono non venire offloadate; per ritardi “sub‑minuto” usa comunque Wait (After Time Interval) ma valuta l’impatto su risorse e timeouts di chiamanti esterni.
Attese lunghe: il Wait è progettato per sospensioni affidabili nel tempo (ore/giorni), con stato persistito.
Considerazioni di affidabilità: preferisci Always‑On per istanze self‑hosted o Cloud; monitora “hanging executions” con alert.

[IMG: Wait node in modalità webhook con pannello Security (JWT, IP whitelist) aperto]

Attese brevi (<65s), timeout e storage dell’esecuzione

Per interazioni “sincrone” con front‑end:

Se devi rispondere al browser entro ~30‑60s, non aspettare che l’utente compili un form: invia “Respond: Immediately” e prosegui con un link di ripresa o un evento successivo.
Per ritardi di pochi secondi, valuta se è davvero necessario “mettere in pausa”: spesso è preferibile proseguire e applicare retry/backoff downstream.

Storage dell’esecuzione:

Le esecuzioni sospese sono persistite: al ripristino dell’istanza, la ripresa funziona regolarmente.
Per grandi volumi di attese simultanee, monitora spazio DB e performance.

Casi d’uso, template e troubleshooting

Galleria di esempi per marketer:

Follow‑up su lead dormienti
Wait: After Time Interval (72 Hours) → se nessuna interazione, invia reminder su Telegram/Email, altrimenti salta.
Approvazione contenuto editoriale
Invia messaggio con {{$execution.resumeUrl}} a chi approva → On Webhook Call → se “approved”, pubblica su LinkedIn/Telegram; se “rejected”, invia richiesta revisione.
Sondaggi rapidi al team
On Form Submitted: raccogli feedback e poi aggiorna un foglio/DB.

Pattern riutilizzabili:

“Wait‑for‑approval”: pacchettizza nodi di messaggistica + Wait (webhook) + switch per esito.
“Time‑gated promo”: Wait (At Specified Time) → push multicanale → log KPI.

Troubleshooting:

Il link di ripresa non funziona (404)
Verifica che l’esecuzione sia ancora in pausa; non riutilizzare URL di run già ripresi.
401/403 su webhook di ripresa
Controlla Authentication (Basic/Header/JWT) e whitelist IP.
Payload non valido in ripresa
Valida Content‑Type e schema del body; se serve Raw Body per HMAC, abilitalo e verifica firma.
Ripresa lenta o timeout lato client
Usa “Respond: Immediately” per acknowledgement rapido; post‑elaborazione asincrona a valle.

[IMG: Canvas con tre template: follow‑up, approvazione, promo time‑gated]

Quick Takeaways

Il nodo Wait di n8n sospende un run e lo riprende su tempo o evento, mantenendo lo stato.
Time‑based: After Time Interval e At Specified Time coprono follow‑up, reminder e lanci.
Event‑based: On Webhook Call e On Form Submitted abilitano approvazioni e input utente.
Usa {{$execution.resumeUrl}} per link/call di ripresa; proteggilo con Basic/Header/JWT e, se serve, whitelist IP.
Scegli la risposta: Immediately (ack veloce), When Last Node Finishes o “Respond to Webhook” per controllo totale.
Per attese brevi (<65s) e front‑end, preferisci ack immediato + ripresa differita; per attese lunghe, affidati al persist storage del Wait.

Conclusione

Il nodo wait n8n è un alleato strategico per orchestrare campagne e processi marketing “a tempo” o “a evento” senza perdere stato né complicare i flussi. Con le modalità After Time Interval e At Specified Time programmi follow‑up e rilasci con precisione; con On Webhook Call e On Form Submitted introduci approvazioni e input human‑in‑the‑loop con link di ripresa univoci ($execution.resumeUrl). La sicurezza integrata (Basic/Header/JWT, whitelist IP, Raw Body) ti permette di proteggere l’ingresso, mentre le opzioni di risposta (immediata, ultimo nodo, Respond to Webhook) ti danno il controllo sull’esperienza lato client. Per massimizzare affidabilità e scalabilità, monitora attese brevi, timeouts e storage, e crea pattern riutilizzabili per approval e promo “time‑gated”. Se sei un/una marketer che vuole imparare ad usare n8n per migliorare la produttività, inizia da un singolo caso d’uso (es. approvazione contenuto), modella la pausa con Wait, e poi estendi a follow‑up, reminder e workflow multi‑canale. Ogni pausa ben progettata è un acceleratore di risultati quando si riaccende al momento giusto.

FAQ

Quando usare il nodo Wait di n8n invece di Cron?

Usa Wait quando vuoi mettere in pausa un workflow n8n già in esecuzione e riprenderlo in seguito (tempo/evento). Cron avvia nuovi run a intervalli; Wait sospende e riprende lo stesso run, mantenendo il contesto.

Come riprendo l’esecuzione via link o API?

Con “On Webhook Call” usa {{$execution.resumeUrl}} per generare un URL di ripresa univoco. Proteggerlo con Authentication (Basic/Header/JWT) e, se possibile, whitelist IP e Raw Body per verifiche aggiuntive.

Posso far rispondere subito chi clicca il link?

Sì. Imposta Respond: Immediately per inviare un 200 OK immediato al chiamante, e continua l’elaborazione nel workflow. In alternativa, “When Last Node Finishes” o “Respond to Webhook” per risposte finali personalizzate.

Cosa considerare per attese brevi e timeout?

Per attese <65s con chiamanti “impazienti” (browser/API), evita di bloccare la risposta: invia ack immediato e gestisci la ripresa in background. Per attese lunghe, il Wait persiste lo stato in modo affidabile.

Il form integrato del Wait è adatto a grandi audience?

Meglio usarlo per approvazioni o input controllati. Per volumi elevati o pubblici, preferisci un “Form Trigger” dedicato, antispam e con gestione allegati separata, e poi riprendi via webhook.

Ci dai una mano?

Ti è stata utile questa guida? Raccontaci nei commenti quale scenario di approvazione o follow‑up vuoi implementare con il nodo Wait di n8n e condividila con il tuo team. Quale automazione metterai “in pausa” per sbloccare al momento perfetto?