Der Lauf ist rot abgebrochen, und die Fehlermeldung spricht Kauderwelsch. Dabei verrät sie fast immer, ob Netz, Daten oder das fremde System schuld sind – man muss nur wissen, wo man hinschaut.

Wer eine Automation in n8n baut, trifft früher oder später auf einen fehlgeschlagenen Lauf (Execution, also eine einzelne Ausführung des Workflows). Ohne diese Unterscheidung ändert man wahllos herum, wartet blind und verliert Stunden.

Ein Fehler hat drei Orte. Erstens die Verbindung zum Netz, also der eigene Server oder das Internet. Zweitens die übergebenen Daten, etwa ein fehlendes oder falsch benanntes Feld. Drittens das angesprochene Zielsystem, also der fremde Dienst selbst. Die Statuscodes (Antwortnummern des Zielsystems) zeigen den Weg: 5xx wie 503 bedeuten, dass der Dienst selbst versagt hat. Ein 400 oder 422 zeigt ungültige Daten. Ein Timeout – die festgelegte Höchstwartezeit, die jeder externe Aufruf braucht – deutet auf das Netz oder einen hängenden Dienst.

Ein Node (ein Verarbeitungsschritt in n8n) bricht mit 401 Unauthorized ab, also fehlerhafte Authentifizierung. Die Datenanzeige unter dem Node zeigt intakte Eingabedaten – es sind also nicht die Daten. Stattdessen prüfen Sie den Eintrag im Credential-Speicher: n8n verwaltet Zugangsdaten getrennt vom Workflow und verschlüsselt sie mit dem Schlüssel aus N8N_ENCRYPTION_KEY.

Verwechselt wird das gerne mit der Annahme, Zugangsdaten müssten dann eben direkt im Workflow stehen. Das ist keine Lösung, sondern eine neue Fehlerquelle. Bei 5xx gilt: Dort liegt die Ursache beim Anbieter, und nur er kann sie oft beheben – ein Retry ist erlaubt, eine Reparatur nicht möglich.

Der abgebrochene Lauf ist nicht ein Fehler, sondern einer von dreien. Erst den Ort bestimmen, dann reparieren – oder beim Anbieter abgeben.

📌 Statuscodes lesen · Drei Fehlerorte · Credentials getrennt speichern

📚 Automatisierung von Grund auf · Tag 4 von 30
#Automatisierung #n8n