n8n Wait-nod: pausa ett workflow och återuppta vid rätt tidpunkt
n8n-serien har hittills täckt noder som transformerar, filtrerar och dirigerar data i realtid. Men vad händer när ditt workflow behöver stanna upp — och sedan fortsätta?
Det är Wait-nodens uppgift.
Vad Wait-noden gör
Wait-noden pausar workflödets exekvering vid en bestämd punkt och återupptar den automatiskt när ett av tre villkor uppfylls. Under pausen är exekveringen vilande i n8n:s databas. Den blockerar inga worker-slots, konkurrerar inte med andra körningar och påverkar inte din generella n8n-prestanda.
De tre lägena
Time interval. Vänta ett fast antal sekunder, minuter, timmar eller dagar. Enklaste läget — du anger hur länge i dropdown-menyn och nummerfält. Används för: fördröjd uppföljningsepost (“skicka påminnelse 48 timmar efter registrering”), stegvisa utskick i en sekvens.
Date and time. Vänta tills ett specifikt datum och klockslag. Värdet kan vara ett hårdkodat datum eller ett dynamiskt värde från ett tidigare nod-resultat — till exempel {{ $json.scheduledAt }}. Används för: schemalagda leveranser, att trigga ett workflow exakt kl 09:00 nästa vardag.
Webhook call. Det mest kraftfulla läget. n8n genererar en unik webhook-URL när exekveringen når Wait-noden. Workflödet pausar och väntar. Skickar du en HTTP-förfrågan till den URL:en — med GET, POST eller valfri metod — återupptas exekveringen och den inkommande requestens data finns tillgänglig i noden.
Godkännandeflödet som praktiskt exempel
Det klassiska användningsfallet för Webhook-läget: ett godkännandeflöde.
- Workflow startar och skapar ett utkast.
- HTTP Request-nod skickar ett e-postmeddelande med en länk:
Klicka här för att godkänna → [webhook-URL] - Wait-nod pausar.
- Mottagaren klickar länken. n8n tar emot GET-förfrågan, exekveringen fortsätter.
- Nästa nod kontrollerar query-parametern (
?approved=yes) och tar rätt väg med en IF-nod.
Hela flödet hanteras utan extern databas, utan polling och utan att din n8n-instans håller en aktiv process öppen under väntetiden.
Viktigt för självhostad n8n
Kontrollera din miljövariabel N8N_EXECUTIONS_TIMEOUT. Standardvärdet är vanligtvis 3600 sekunder (1 timme). En Wait-nod som väntar längre än detta värde avbryts tyst — ingen retry, inget felmeddelande i UI:t. Exekveringen försvinner bara.
Om du kör Wait-noder med längre väntetider (24 timmar, 7 dagar) behöver du antingen:
- Höja
N8N_EXECUTIONS_TIMEOUTtill ett lämpligt värde, eller - Strukturera om flödet så att den väntande exekveringen triggas av en ny Schedule Trigger eller webhook istället.
n8n Cloud hanterar långa väntetider bättre, men kontrollera alltid aktuell dokumentation för din plan.
När du inte ska använda Wait-noden
Om du bara vill att ett workflow körs vid ett bestämt klockslag varje dag, använd Schedule Trigger — inte Wait. Schedule Trigger är en riktig schemaläggare; Wait-noden är en paus mitt i ett redan körande workflow.
Fördröjningar under en sekund hanteras bäst i ett Code-nod med setTimeout (JavaScript) om du verkligen behöver dem. Wait-nodens minsta granularitet är en sekund och den har overhead för att serialisera och deserialisera exekveringstillståndet.
Vanliga frågor
Kan en Wait-nod vänta flera dagar?
Ja, i teorin. I praktiken: kontrollera N8N_EXECUTIONS_TIMEOUT på din n8n-instans. Om din väntid överskrider timeout-gränsen avbryts exekveringen. n8n Cloud har generellt högre gränser än en standardinstallation.
Vad händer med webhook-URL:en om ingen klickar?
URL:en är giltig tills exekveringen avbryts (av timeout eller att du manuellt stoppar den). Om timeout nås utan att webhook anropas markeras exekveringen som misslyckad. Du kan koppla felhantering via en Error Trigger-nod för att hantera timeout-fallen.
Kan jag skicka med data i webhook-anropet?
Ja. En POST-förfrågan med en JSON-body gör att den inkommande datan finns tillgänglig i Wait-nodens output — du kan läsa den i nästkommande noder precis som du läser data från en vanlig Webhook-trigger.