n8n vs. eigene Skripte und Cron-Jobs: Wann lohnt sich was?

n8n lohnt sich dann, wenn eine Automatisierung mehrere Systeme verbindet, wiederkehrend läuft und im Fehlerfall nachvollziehbar bleiben muss. Ein eigenes Skript mit Cron-Job ist oft in einer halben Stunde getippt, wird aber schnell zur stillen Wartungslast, sobald sich eine API ändert, ein Token abläuft oder ein Kollege die Logik verstehen muss, ohne den Code zu lesen. Laut der offiziellen n8n-Dokumentation ist n8n „a fair-code licensed workflow automation tool that combines AI capabilities with business process automation" und verbindet damit einen visuellen Workflow-Editor mit echtem Code, wo dieser wirklich gebraucht wird. Stand: Juli 2026.

Die Entscheidung zwischen n8n und einem selbstgeschriebenen Skript ist keine Glaubensfrage, sondern eine Frage der Anzahl beteiligter Systeme, der Fehleranfälligkeit und davon, wer das Ergebnis später pflegen muss. Dieser Artikel zeigt anhand der n8n-Dokumentation, wo die Grenze verläuft und wann sich der Umstieg von einer Crontab-Zeile auf einen Workflow tatsächlich lohnt.

Was ein eigenes Skript mit Cron-Job leisten muss

Ein klassisches Setup aus Skript und Cron-Job klingt zunächst simpel: eine Datei, ein Zeitplan-Eintrag, fertig. In der Praxis übernimmt das Skript aber deutlich mehr, sobald es produktiv läuft. Es muss sich gegen mehrere APIs authentifizieren, Antworten parsen und auf Formatänderungen reagieren, Fehler abfangen statt sie stillschweigend zu verschlucken, Logs schreiben, die im Ernstfall auch jemand liest, und im Idealfall noch jemanden benachrichtigen, wenn ein Lauf fehlschlägt. All das schreibt sich niemand beim ersten Wurf mit, es kommt Stück für Stück dazu, meist erst nachdem ein Lauf unbemerkt tagelang nichts getan hat. Genau dieser nachträgliche Ausbau ist der Teil, der bei Skript-und-Cron-Lösungen am meisten Zeit frisst, nicht die ursprüngliche Automatisierung selbst.

Was n8n zusätzlich mitbringt

n8n ersetzt das Grundgerüst aus Authentifizierung, Datenverarbeitung und Zeitsteuerung durch vorgefertigte Nodes, ohne dir den Code komplett wegzunehmen. Wo die eingebauten Nodes nicht reichen, gibt es den Code-Node: Er führt eigenes JavaScript oder Python direkt im Workflow aus, bei selbstgehosteten Instanzen sogar mit Zugriff auf externe npm-Module, wie die Dokumentation zum Code-Node beschreibt. In der Cloud-Version ist der Modulzugriff eingeschränkter. Für den Betrieb selbst hast du außerdem die Wahl: n8n lässt sich per npm, Docker oder bei Anbietern wie AWS, Hetzner oder DigitalOcean selbst hosten, wie die Übersicht zum Self-Hosting zeigt. Du behältst damit die Kontrolle über Infrastruktur und Daten, statt dich an eine reine Cloud-Lösung zu binden.

Zeitplanung: Schedule Trigger statt Crontab

Der direkte Ersatz für die Crontab ist in n8n der Schedule-Trigger-Node. Er startet Workflows zu festen Zeiten oder Intervallen, ähnlich wie das Unix-Cron-Dienstprogramm, bietet dafür aber sieben Konfigurationsarten von Sekunden- und Minutenintervallen bis zu benutzerdefinierten Cron-Ausdrücken im sechsteiligen Format inklusive Sekundenfeld, wie in der Dokumentation zum Schedule-Trigger-Node beschrieben. Wer eine bestehende Cron-Syntax mitbringt, kann sie also fast unverändert übernehmen, muss aber keine eigene Zeitsteuerung im Skript pflegen und sieht direkt in der Oberfläche, wann ein Workflow zuletzt und als Nächstes läuft.

Fehlerbehandlung: wo n8n einem stillen Cron-Fehler voraus ist

Ein Cron-Job, der scheitert, meldet das im schlechtesten Fall gar nicht, im besten Fall in einer Logdatei, die niemand automatisch prüft. n8n bietet dafür ein eingebautes Konzept: Für jeden Workflow lässt sich in den Einstellungen ein separater Error-Workflow hinterlegen, der bei einem Fehlschlag automatisch startet und über den Error-Trigger-Node Details wie Fehlermeldung, betroffenen Node und Ausführungs-ID erhält. Ergänzend gibt es den Stop-And-Error-Node, um Ausführungen gezielt unter bestimmten Bedingungen fehlschlagen zu lassen, sowie die Retry-on-Fail-Option an einzelnen Nodes. Details dazu stehen in der Anleitung zur Fehlerbehandlung. Damit lässt sich eine Benachrichtigung bei Fehlern einrichten, ohne dafür zusätzlichen Code zu schreiben.

Wann eigene Skripte und Cron-Jobs die bessere Wahl bleiben

• Eine einzelne, sehr spezifische Aufgabe ohne Anbindung an weitere Systeme, etwa das Rotieren von Logdateien auf einem Server.
• Extrem performancekritische Verarbeitung großer Datenmengen, bei der ein schlankes, kompiliertes oder stark optimiertes Skript spürbar schneller ist als ein Workflow mit mehreren Nodes.
• Anbindung an Legacy-Systeme ohne API, für die es ohnehin schon eine gewachsene, gut dokumentierte Skript-Landschaft gibt und ein Wechsel keinen echten Mehrwert bringt.
• Ein Team, in dem ausschließlich erfahrene Entwickler arbeiten und niemand sonst den Ablauf jemals einsehen oder anpassen muss.

Wann n8n die bessere Wahl ist

• Mehrere Systeme und APIs müssen zuverlässig miteinander verbunden werden, etwa CRM, E-Mail-Versand und eine Tabellenkalkulation in einem Ablauf.
• Auch Kolleginnen und Kollegen ohne Entwicklerhintergrund sollen den Workflow nachvollziehen oder kleine Anpassungen selbst vornehmen können.
• Fehlerbehandlung, Logging und Benachrichtigung bei Fehlschlägen sollen von Anfang an dabei sein, ohne dass du sie separat programmierst.
• Du willst die Infrastruktur selbst hosten und die Kontrolle über Daten und Deployment behalten, statt dich in ein reines Cloud-Abo einzukaufen.

Wer unsicher ist, ob eine geplante Automatisierung eher ein schlankes Skript bleibt oder sich als n8n-Workflow mehr lohnt, bekommt im Rahmen der n8n-Beratung von NordFlux eine ehrliche Einschätzung, bevor Zeit in die falsche Lösung fließt.

Häufige Fragen

Kann ich in n8n trotzdem eigenen Code schreiben?

Ja. Der Code-Node führt JavaScript oder Python direkt im Workflow aus, sodass du Logik, die kein Standard-Node abdeckt, weiterhin selbst programmierst. Bei selbstgehosteten Instanzen kannst du dabei sogar externe npm-Module einbinden, in der Cloud-Version ist der Zugriff auf Module eingeschränkter.

Ersetzt n8n Cron-Jobs komplett?

Für die reine Zeitsteuerung ja, der Schedule-Trigger-Node deckt Intervalle von Sekunden bis Monaten sowie freie Cron-Ausdrücke ab. Für Systemaufgaben außerhalb von Workflows, etwa das Aufräumen von Log-Verzeichnissen direkt auf einem Server, bleibt ein klassischer Cron-Job weiterhin sinnvoll.

Was passiert, wenn ein n8n-Workflow fehlschlägt?

Du kannst pro Workflow einen Error-Workflow hinterlegen, der bei einem Fehlschlag automatisch startet und über den Error-Trigger-Node Details zum Fehler erhält. So lässt sich eine Benachrichtigung, etwa per E-Mail oder Chat, einrichten, ohne dass du das selbst programmieren musst.

Lohnt sich n8n für eine einzelne, einfache Automatisierung?

Nicht zwangsläufig. Wenn es bei einer isolierten Aufgabe ohne weitere Systeme bleibt, ist ein kurzes Skript mit Cron-Job oft schneller umgesetzt und verursacht weniger laufenden Betriebsaufwand als eine zusätzliche Plattform.

Brauche ich Programmierkenntnisse für n8n?

Für viele Standard-Workflows nicht, da sich Verbindungen zwischen Systemen über vorgefertigte Nodes klicken lassen. Sobald du individuelle Logik brauchst, hilft es, JavaScript oder Python zumindest lesen zu können, weil der Code-Node genau dafür gedacht ist.