Pour ceux qui gèrent des workflows n8n pour des clients — comment découvrez-vous quand quelque chose se casse ?

Décrivez le problème/l’erreur/la question

J’exécute des automatisations dans n8n pour une poignée de clients, et la partie qui me stresse n’est pas la construction — c’est de ne pas savoir quand quelque chose cesse tranquillement de fonctionner.

Quel est le message d’erreur (le cas échéant) ?

Veuillez partager votre flux de travail

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)

Partagez la sortie renvoyée par le dernier nœud

Informations sur votre configuration n8n

  • Version n8n :
  • Base de données (par défaut : SQLite) :
  • Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
  • n8n en cours d’exécution via (Docker, npm, n8n cloud, application de bureau) :
  • Système d’exploitation :
1 « J'aime »

Texte brut

Je comprends parfaitement. Le scénario de « rupture silencieuse » est exactement ce qui tient les architectes d'automatisation éveillés la nuit, surtout lorsqu'ils gèrent les flux de travail des clients.

La meilleure et la plus scalable façon de gérer cela dans n8n n'est pas d'ajouter une logique de gestion des erreurs à chaque flux de travail, mais de créer un **Global Error Workflow** centralisé.

n8n dispose d'un nœud `Error Trigger` dédié. Lorsqu'il est configuré dans un flux de travail autonome, il agit comme un écouteur global. Chaque fois qu'*un* flux de travail actif dans toute votre instance n8n échoue, ce déclencheur le détecte et extrait toutes les métadonnées (nom du flux de travail, nœud qui a échoué, message d'erreur, ID d'exécution).

Voici un modèle prêt à l'emploi pour un Global Error Notifier. Copiez simplement ce JSON et collez-le dans un nouveau flux de travail vierge :

```json
{
  "nodes": [
    {
      "parameters": {},
      "type": "n8n-nodes-base.errorTrigger",
      "typeVersion": 1,
      "position": [240, 240],
      "id": "2498e94e-d00d-4054-9988-518201a052e4",
      "name": "Error Trigger (Catch All)"
    },
    {
      "parameters": {
        "mode": "json",
        "json": {
          "workflowName": "={{ $json.context.workflow.name }}",
          "workflowId": "={{ $json.context.workflow.id }}",
          "executionId": "={{ $json.context.execution.id }}",
          "errorNodeName": "={{ $json.error.context.node.name }}",
          "errorMessage": "={{ $json.error.message }}",
          "timestamp": "={{ new Date().toISOString() }}"
        },
        "options": {}
      },
      "type": "n8n-nodes-base.set",
      "typeVersion": 1,
      "position": [480, 240],
      "id": "e914041a-a131-4a4b-8526-a05d6888c3a5",
      "name": "Format Error Data"
    },
    {
      "parameters": {
        "fromEmail": "n8n@yourdomain.com",
        "toEmail": "youremail@yourdomain.com",
        "subject": "🚨 n8n Workflow Failed: {{ $json.workflowName }}",
        "text": "Bonjour,\n\nUn flux de travail n8n a échoué de manière inattendue.\n\n----------------------------------------\nNom du flux de travail : {{ $json.workflowName }}\nID du flux de travail : {{$json.workflowId }}\nID d'exécution : {{ $json.executionId }}\nNœud ayant échoué : {{$json.errorNodeName }}\nMessage d'erreur : {{ $json.errorMessage }}\nHorodatage : {{$json.timestamp }}\n----------------------------------------\n\nVeuillez vérifier les exécutions de votre instance n8n.",
        "options": {}
      },
      "type": "n8n-nodes-base.emailSend",
      "typeVersion": 1,
      "position": [720, 240],
      "id": "766a2673-8181-4200-a07c-95c52c035661",
      "name": "Email Send (Error Alert)"
    }
  ],
  "connections": {
    "Error Trigger (Catch All)": {
      "main": [
        [
          {
            "node": "Format Error Data",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Format Error Data": {
      "main": [
        [
          {
            "node": "Email Send (Error Alert)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

Comment l’utiliser :

  1. Collez ceci dans un nouveau flux de travail.

  2. Ouvrez le nœud Email Send (ou remplacez-le par un nœud Slack/Discord si vous préférez les alertes par chat).

  3. Connectez vos identifiants e-mail et définissez votre toEmail.

  4. Activez ce flux de travail.

Maintenant, vous pouvez être tranquille. Si quelque chose échoue silencieusement, vous recevrez instantanément un e-mail avec les détails exacts de ce qui s’est cassé et où !

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 « J'aime »

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.

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.”