Für diejenigen, die n8n-Workflows für Kunden verwalten – wie findet ihr heraus, wenn etwas kaputtgeht?

Feedback General
1

Problem/Fehler/Frage beschreiben

Ich führe Automatisierungen in n8n für eine Handvoll Kunden durch, und das, das mir Kopfschmerzen bereitet, ist nicht das Erstellen — es ist nicht zu wissen, wenn etwas stillschweigend kaputt geht.

Welche Fehlermeldung wird angezeigt (falls vorhanden)?

Bitte teilen Sie Ihren Workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Ausgabe des letzten Knotens teilen

Informationen zu Ihrem n8n-Setup

  • n8n-Version:
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main):
  • n8n wird ausgeführt über (Docker, npm, n8n cloud, Desktop-App):
  • Betriebssystem:
1 „Gefällt mir“
2

Klartext

Hey! Das ist völlig verständlich. Das Szenario des „stillen Scheiterns
4

Following up on this since a few people asked how I ended up detecting these.

The short version: n8n’s execution status alone misses an entire class. A node set to continue-on-fail records its error inside data.resultData.runData[nodeName][].error while the run still reports success. You need includeData=true to see it at all.

I wrote up what I found, including two classification mistakes that took me a while to notice — one of them being that a dead Google credential often surfaces with no HTTP code at all: Why n8n says a workflow succeeded when it didn't — Okum

If anyone has hit a failure shape that doesn’t fit, I’d like to hear it.

1 „Gefällt mir“
5

The failure the Error Trigger can’t see is the one that actually burns you: a workflow that never runs. If a trigger silently dies or Cloud auto-deactivates after a hard crash, nothing errors, so nothing alerts.

I’d pair the global Error Trigger with one heartbeat workflow on a schedule that hits the public API per client flow — GET /api/v1/executions?workflowId=… and compare the newest startedAt against the window that flow is supposed to run in, plus GET /api/v1/workflows/{id} to confirm active is still true. One catches loud failures, the other catches silence.

6

The silence case is the one I keep coming back to as well, and your split is right — one catches loud failures, the other catches absence.

One cause of it that surprised me: a workflow can be deployed and simply never activate, with no error anywhere. I hit this with form and webhook triggers — deploy the same template to a second client and both copies claim the same URL path, so n8n refuses to activate the second one. It shows as saved and looks fine in the list, but it has never run once. GET /api/v1/workflows/{id} and checking active is the only thing that catches it, exactly as you said.

Worth checking that alongside the heartbeat, since a workflow that never activated has no startedAt to compare against at all — there’s no history to notice a gap in.

Have you found a reliable window per workflow, or do you set the expected interval by hand per client? That’s the part I haven’t solved — a flow that runs hourly and one that runs on a form submission need very different definitions of “too quiet.”