Eine Automatisierung soll auf ein Ereignis reagieren – eine neue Bestellung, eine eingehende E-Mail, ein ausgefülltes Formular. Aber reagiert sie in dem Moment, in dem das passiert, oder erst beim nächsten Kontrollblick? Genau hier scheiden sich zwei Bauweisen: der Webhook und das Polling. Den Unterschied merken Geschäftsführer meist erst, wenn eine Benachrichtigung Minuten zu spät kommt – oder ganz ausbleibt. Dieser Artikel erklärt beide Wege, ihre ehrlichen Vor- und Nachteile und wie Sie in n8n den richtigen Auslöser wählen.
Push oder Pull: zwei Wege, von einem Ereignis zu erfahren
Eine Automatisierung kann auf zwei Arten von einem Ereignis erfahren. Beim Webhook (Push) meldet sich das auslösende System von selbst und schickt die Daten in dem Augenblick, in dem etwas passiert. Beim Polling (Pull) fragt die Automatisierung in festen Abständen nach: „Gibt es etwas Neues?“ Der erste Weg ist ein Anruf, sobald etwas passiert; der zweite ein regelmäßiger Kontrollblick.
In n8n entscheiden Sie das mit der Wahl des Trigger-Nodes. Der Webhook-Node wartet auf eingehende Anfragen – das ist der Push-Weg. Der Schedule Trigger und die meisten App-Trigger (etwa für Gmail oder ein CRM) arbeiten dagegen per Polling: n8n verbindet sich, wie die n8n-Dokumentation es beschreibt, „alle X Zeiteinheiten mit dem Server und prüft, ob neue Daten da sind“. Welcher Weg der richtige ist, hängt von zwei Fragen ab: Wie schnell muss es gehen – und wie zuverlässig ist die Quelle erreichbar?
Der Webhook: sofort, aber nur, wenn jemand zuhört
Ein Webhook liefert das Ereignis praktisch in Echtzeit, oft im Millisekundenbereich. Das auslösende System schickt eine HTTP-Anfrage an Ihre n8n-Adresse, und der Workflow startet sofort. Der Webhook-Node nimmt Anfragen per POST, GET, PUT, PATCH, DELETE und HEAD entgegen und antwortet wahlweise sofort, erst wenn der letzte Node fertig ist oder über einen eigenen „Respond to Webhook“-Node. Absichern lässt er sich per Basic-, Header- oder JWT-Authentifizierung; produktiv aktiv wird die Adresse, sobald der Workflow veröffentlicht ist.
Der Push-Weg hat aber eine Bedingung: Jemand muss zuhören. Ist Ihre n8n-Instanz im Moment des Ereignisses nicht erreichbar – ein Neustart, ein Netzwerkfehler, ein Wartungsfenster –, geht die Meldung verloren, sofern das absendende System sie nicht erneut zustellt. Manche Dienste wiederholen fehlgeschlagene Zustellungen über mehrere Tage (Zahlungsdienste wie Stripe etwa), andere senden genau einmal und nie wieder. Hinzu kommt: Der Webhook-Node bringt keine eingebaute Deduplizierung mit. Ein Dienst, der nach ausbleibender Antwort erneut sendet, löst den Workflow zweimal aus – wie Sie doppelte Aktionen in Automatisierungen verhindern, ist deshalb gerade bei Webhooks ein eigenes Thema.
Das Polling: im Takt, dafür nachsichtig
Beim Polling fragt n8n das Quellsystem aktiv in festen Abständen ab. Der Schedule Trigger steuert das über Intervalle in Sekunden, Minuten, Stunden, Tagen, Wochen, Monaten oder einen eigenen Cron-Ausdruck; App-Trigger wie der Gmail-Trigger nutzen dafür das Feld „Poll Times“ mit denselben Optionen. Die maximale Verzögerung entspricht dem Intervall: Wer alle fünf Minuten abfragt, erfährt von einem Ereignis spätestens nach fünf Minuten – nie schneller.
Diese Trägheit ist zugleich eine Stärke: Polling ist nachsichtig gegenüber Ausfällen. War die Instanz zwanzig Minuten offline, holt der nächste Abruf alles Liegengebliebene nach. Gut gebaute Polling-Trigger merken sich dabei den Stand der letzten Abfrage – n8n speichert das intern über die statischen Workflow-Daten – und liefern nur echte Neuzugänge, statt bei jedem Lauf alles erneut zu verarbeiten.
Der Preis dafür ist Leerlauf. Jede Abfrage kostet einen API-Aufruf, auch wenn nichts Neues da ist. Bei knappen API-Limits oder sehr kurzen Intervallen summiert sich das schnell: Rechnen Sie eine Abfrage alle dreißig Sekunden über viele Postfächer oder Konten hoch, landen Sie bei Tausenden Anfragen pro Tag, von denen die meisten leer zurückkommen. Manche Schnittstellen drosseln oder sperren dann wegen zu vieler Anfragen.
Die ehrliche Faustregel: Ein Webhook ist schnell, aber vergesslich – verpasst er ein Ereignis, ist es weg. Polling ist langsamer, dafür beharrlich – es holt nach, was liegen geblieben ist. Die Frage ist also nicht, welches Verfahren grundsätzlich besser ist, sondern ob Ihr Prozess eher Tempo oder Verlässlichkeit braucht. Oft braucht er beides.
Wann nehme ich was?
Für die Entscheidung reichen zwei Kriterien: das geforderte Tempo und die Frage, ob die Quelle Webhooks überhaupt anbietet. Die folgende Tabelle fasst die typischen Fälle zusammen.
| Situation | Sinnvoller Auslöser |
|---|---|
| Reaktion muss in Sekunden erfolgen | Webhook |
| Quellsystem bietet keine Webhooks an | Polling |
| Planbare Stapelverarbeitung (z. B. nächtlich) | Polling (Schedule Trigger) |
| Hohes Aufkommen, viele Leerabfragen vermeiden | Webhook |
| Quelle ist nur unzuverlässig erreichbar | Polling (holt nach) |
Ob eine Quelle Webhooks unterstützt, steht in deren Dokumentation, meist unter dem Stichwort „Webhooks“. Zahlungsdienste, Shop-Systeme, Formularanbieter und viele CRM-Lösungen bringen sie mit. Fehlt diese Möglichkeit – etwa bei älterer Software, die nur eine reine Abfrage-API hat –, bleibt Polling der einzige Weg. Und für klassische Stapelverarbeitung, die ohnehin nur einmal pro Nacht laufen soll, ist ein Zeitplan-Trigger schlicht das passende Werkzeug.
Der robuste Weg: beides kombinieren
In der Praxis schließen sich beide Verfahren nicht aus. Die verlässlichste Architektur nutzt den Webhook als schnellen Hauptkanal und ein regelmäßiges Polling als Sicherheitsnetz, das nachholt, was der Webhook bei einem Ausfall verpasst hat. Große Anbieter wie Shopify empfehlen genau diesen Abgleich – und weisen ausdrücklich darauf hin, dass derselbe Webhook dabei mehr als einmal ankommen kann.
Dieser Doppelweg hat zwei Voraussetzungen, sonst handeln Sie sich neue Probleme ein. Erstens muss die Verarbeitung idempotent sein: Jedes Ereignis darf genau einmal wirken, egal ob es über den Webhook, das Polling oder beide hereinkommt. Zweitens braucht der Webhook-Kanal eine Überwachung, denn ein stiller Ausfall fällt sonst niemandem auf – wie Sie Fehler in Automatisierungen früh erkennen, gehört untrennbar dazu. Bei der konkreten Einrichtung dieser Trigger und Sicherungen in n8n unterstütze ich Sie in der n8n-Beratung.
Welcher Auslöser zu Ihrem Prozess passt, hängt am Ende nur davon ab, wie schnell er reagieren muss und wie zuverlässig Ihre Quellsysteme erreichbar sind – das lässt sich meist in wenigen Minuten klären. Wenn Sie unsicher sind, ob ein Vorhaben eher Webhook, Polling oder die Kombination braucht: In einem kostenlosen Prozess-Check schauen wir uns gemeinsam an, welcher Weg für Ihre Systeme der tragfähige ist – ehrlich, auch wenn die Antwort manchmal „der einfache Zeitplan reicht“ lautet.