Wie du API-Fehlermeldungen liest, ohne Technikerdeutsch zu können

Nummer und Text: woraus eine Meldung besteht

Ruft ein Baustein in n8n einen anderen Dienst auf, antwortet dieser mit einem Statuscode. Geht etwas schief, siehst du zwei Teile: die Nummer und einen erklärenden Text.

Der Text ist oft englisch und technisch formuliert. Die Nummer dagegen folgt einem festen Schema, das für alle Dienste im Netz gleich ist. Darum beginnst du mit ihr.

Wie Fehlersuche bei mir früher aussah

Früher, ohne KI, ging die meiste Zeit für die Suche nach Fehlern drauf. Oft war es ein Leerzeichen irgendwo, und der Ablauf lief nicht. Ein Klassiker war ein Stück Code, das ich aus einem Editor kopiert und eingefügt habe, ohne zu prüfen, ob es sauber mitkommt.

Für Code-Schnipsel arbeite ich darum mit Sublime Text. Für dieselbe Arbeit, also Fehlersuche und Abläufe zum Laufen bringen, waren früher 3 Personen nötig. Heute schafft das bei mir 1 Person in der gleichen Zeit.

Die Nummer zuerst: bei dir oder beim Dienst

MDN teilt die Statuscodes in Klassen ein. Wichtig für dich sind diese: 400–499 heissen «Client error responses», also Client-Fehler. Die Anfrage von deiner Seite war nicht in Ordnung. 500–599 heissen «Server error responses», also Server-Fehler. Der angefragte Dienst konnte die Anfrage nicht bearbeiten.

• 401 Unauthorized: Der Zugang fehlt oder ist falsch. Prüf die Zugangsdaten im Baustein.
• 403 Forbidden: Der Zugang ist da, aber er hat keine Berechtigung für diese Aktion.
• 404 Not Found: Die Adresse, die dein Baustein aufruft, gibt es nicht.
• 429 Too Many Requests: Dein Workflow hat in kurzer Zeit zu viele Anfragen geschickt.

• 500 Internal Server Error: Beim Dienst ist etwas schiefgelaufen, das er selbst nicht einordnen kann.
• 502 Bad Gateway: Ein Server dazwischen hat eine ungültige Antwort bekommen.
• 503 Service Unavailable: Der Dienst ist gerade nicht bereit, oft wegen Wartung oder Überlast.

Bei einem Server-Fehler liegt es in der Regel nicht an dir. Du wartest und versuchst es später nochmals, oder du meldest es dem Anbieter. Ein Versprechen, dass sich das von selbst löst, gibt es nicht.

Den Text erklärt dir die KI

Die vollständige Meldung findest du in n8n unter «Executions». Laut n8n-Doku ist eine Execution ein einzelner Lauf eines Workflows; die Ansicht zeigt dir die Läufe pro Workflow oder alle zusammen, auch die fehlgeschlagenen.

Öffne den fehlgeschlagenen Lauf und gib der KI genau drei Angaben: den Wortlaut der Meldung, den Baustein, der stehen geblieben ist, und was du unmittelbar davor geändert oder getan hast. Ohne sie bleibt auch die beste Erklärung allgemein.

Wie schon beim ersten Workflow gilt: Bevor du etwas in einen Chat kopierst, nimmst du Zugangsschlüssel, Passwörter und Kundendaten heraus. Die KI erklärt dir dann den Text und schlägt vor, was du als Nächstes prüfst, zum Beispiel ob irgendwo ein Zeichen nicht stimmt. Ob der Workflow danach läuft, zeigt dir erst der nächste Testlauf.

Was dir die gewonnene Zeit bringt

Bei mir: Seit ich mit KI arbeite, passieren solche dummen Fehler deutlich seltener. Die frei gewordene Zeit fliesst in Sicherheit und in die Frage, wer in einem System was darf. Ein Backend-Projekt braucht dafür ehrlicherweise einfach mehr Zeit.

Dazu kommt die Frage nach dem Aufbau: ein grosses System oder Microservices, also viele kleine Dienste. Ich werde dabei mehr zum Systemarchitekten. Die KI gibt mir viele kleine Helfer, und ich koordiniere sie.