Trigger Node

Der Trigger Node ist der Startknopf für jede Automatisierung. Jeder Workflow in n8n muss irgendwo beginnen. Ein Auto fährt nicht los, ohne dass jemand den Schlüssel dreht. Der Trigger ist dieser Schlüssel. Er wartet geduldig auf ein bestimmtes Ereignis und sagt dann: "Los geht's!" an alle nachfolgenden Nodes.

Stell dir einen Wachhund vor:

Er schläft die ganze Zeit (braucht keine Energie).
Aber sobald der Postbote kommt (Ereignis), bellt er los (Startet den Workflow).

Merksatz: Der erste Baustein, der definiert, wann dein Workflow laufen soll.

Es gibt drei Haupt-Arten von Triggern, die du ständig brauchst:

App Trigger (Push): "Wenn eine neue E-Mail in Gmail ankommt." Das ist der häufigste Fall. Der Workflow startet sofort, wenn in einer anderen App etwas passiert.
Schedule Trigger (Zeit): "Jeden Montag um 09:00 Uhr." Perfekt für Reports oder Aufräum-Arbeiten. Wie dein Wecker.
Webhook Trigger (Universal): "Wenn jemand diese URL aufruft." Damit kannst du n8n von überall aus fernsteuern (z. B. aus einem WordPress-Formular).

Wichtig: Ein Workflow kann mehrere Trigger haben! Du kannst sagen: "Starte, wenn eine E-Mail kommt ODER wenn es 17:00 Uhr ist."

Polling vs. Pushing

Nicht alle Trigger sind gleich schnell.

Polling (Die nervige Frage): Der Trigger fragt alle 60 Sekunden bei der App nach: "Hast du was neues? ... Hast du jetzt was neues?"
- Nachteil: Es gibt eine Verzögerung von bis zu einer Minute.
- Erkennbar: Im n8n Editor steht oft "Poll" am Node.
Pushing (Webhook): Die App meldet sich aktiv bei n8n: "Hier ist was neues!"
- Vorteil: Echtzeit (Real-time). Der Workflow startet Millisekunden später.

Manuelles Testen

Wenn du im Editor auf "Execute Workflow" klickst, umgehst du den Trigger oft. Aber: Manche Trigger (wie Webhooks) müssen von außen aufgerufen werden, damit du Testdaten bekommst. Dafür hat n8n den Test-Modus. Der Webhook-Node zeigt dir dann eine spezielle "Test-URL", die nur für diesen einen Versuch gültig ist.

Long-Polling (Der Batterie-Retter)

Einige APIs senden keine push-basierten Webhooks, aber minütliches Polling verbraucht drastisch API-Credits. Stattdessen implementieren Nodes oft Long-Polling. Hierbei öffnet der n8n Trigger-Node eine HTTP-Request zur Ziel-API. Die API blockt diese Verbindung gezielt und hält den TCP-Socket für ca. 30 Sekunden offen. Passiert in dieser Zeit etwas, antwortet die API im Socket und schließt ihn (n8n startet den Run). Passiert nichts, läuft der TCP Timeout, und n8n öffnet leise einen neuen Request. Es kombiniert die Echtzeitigkeit eines Webhooks mit dem Fire-wall-freundlichen Auswärts-Verhalten (Outbound) von Polling.

Polling-Trigger State Management

Wie weiß ein Polling-Trigger ("Hole E-Mails alle 5 Minuten"), welche E-Mails er schon gelesen hat, wenn n8n restartet? Er nutzt den unsichtbaren Static Data Speichermechanismus von n8n. Er schreibt in die interen SQLite/Postgres DB des Triggers eine Referenz (lastFetchedId = 9012). Startet das System nach einem Server-Crash neu, bootet der Trigger, liest diesen persistenten State aus der Config und fragt die API präzise: "Gib mir alle Mails >= 9012". (Dies fällt leider aus, wenn Worker-Muster ohne DB-Sync genutzt werden, was zu Duplicate-Runs führen kann).

Worker Node Architecture (Scale-Out Triggers)

Wenn n8n im Queue-Mode (mit Redis + RabbitMQ) läuft, wer hält dann die Trigger am Leben? Nicht die Worker! Worker-Container sind reine "Execution"-Schlampen, die auf Befehle warten. Es gibt zwingend den n8n Main-Prozess (Webhook/Scheduler-Instanz), der als einzige Instanz den node-cron oder den Express.js Webhook-Listener bindet. Zündet ein Webhook-Trigger, packt der Main-Prozess den HTTP-Payload in die Redis-Queue und beendet sofort den Request mit einem 200 OK Accepted. Es ist die Aufgabe eines Workers, den Batch aufzunehmen und die Nodes unterhalb des Triggers asynchron auszuführen. Das schützt den Ingress vor Blockierungen bei Heavy-Compute Tasks.