Introduction

Dans tout workflow de production, des choses vont mal se passer. Une API renvoie un 500, un payload de webhook est mal formé, une connexion à une base de données expire. La question n'est pas de savoir si des échecs surviennent — c'est de savoir si votre workflow les gère avec élégance ou s'il laisse passer le problème en silence.

n8n vous offre deux couches de gestion des erreurs : une gestion locale au niveau du nœud, et un nœud Error Trigger dédié qui vous permet de construire un workflow séparé spécifiquement destiné à intercepter et réagir aux échecs. Cette leçon couvre les deux, avec un accent sur l'envoi d'alertes concrètes entre vos mains lorsque quelque chose casse.

Comment n8n gère les échecs de nœuds par défaut

Par défaut, lorsqu'un nœud génère une erreur, n8n arrête l'exécution pour ce chemin et marque l'exécution comme échouée. Vous verrez l'erreur dans l'historique d'exécution, mais rien de proactif ne se passe — aucune alerte, aucun retry, aucun fallback.

Pour chaque nœud, vous pouvez modifier ce comportement dans le panneau de paramètres du nœud. Les trois options les plus utiles sont :

Stop workflow on error — le comportement par défaut. L'exécution s'arrête au niveau du nœud en échec.

Continue on error — n8n transmet l'exécution en aval même si le nœud échoue. L'élément de sortie du nœud en échec portera les informations d'erreur dans un champ spécial, que vous pouvez inspecter en aval.

Retry on fail — n8n réessaie automatiquement le nœud un nombre configurable de fois avec un délai entre les tentatives. C'est utile pour les échecs transitoires comme les réponses de rate-limiting ou les appels réseau instables.

Pour configurer ces options, ouvrez n'importe quel nœud, allez dans Settings, et cherchez la section « On Error ». Pour le retry, vous devez également passer « Retry On Fail » à true et définir « Max Tries » et « Wait Between Tries » en millisecondes.

Continue on error est particulièrement puissant lorsque vous voulez traiter un lot d'éléments sans qu'un mauvais enregistrement tue toute l'exécution. Le nœud en aval reçoit un élément qui ressemble à ceci :

{
  "error": {
    "message": "Request failed with status code 404",
    "node": "HTTP Request",
    "stack": "..."
  }
}

Vous pouvez ensuite utiliser un nœud IF pour vérifier si l'élément possède un champ d'erreur et le router vers une branche séparée pour le logging ou l'alerte.

Configurer un Error Workflow avec le Error Trigger

Les paramètres au niveau du nœud gèrent les échecs individuels, mais comment intercepter n'importe quel échec sur l'ensemble d'un workflow ? C'est à cela que sert le nœud Error Trigger.

Le Error Trigger fonctionne au niveau du workflow. Vous créez un workflow séparé — appelez-le par exemple « Global Error Handler » — et vous définissez son déclencheur sur Error Trigger. Ensuite, dans n'importe quel autre workflow, allez dans Settings et renseignez le champ « Error Workflow » pour qu'il pointe vers ce workflow gestionnaire.

Lorsque le workflow parent échoue, n8n démarre automatiquement le workflow gestionnaire d'erreurs et lui transmet un payload contenant les détails de ce qui s'est mal passé. La structure du payload ressemble à ceci :

{
  "execution": {
    "id": "1042",
    "url": "https://your-n8n.com/execution/1042",
    "retryOf": null,
    "error": {
      "message": "Could not connect to the database",
      "stack": "Error: Could not connect..."
    },
    "lastNodeExecuted": "Postgres",
    "mode": "trigger"
  },
  "workflow": {
    "id": "88",
    "name": "Daily Invoice Sync"
  }
}

Cela vous donne tout ce dont vous avez besoin : quel workflow a échoué, quel nœud était le dernier à s'être exécuté, le message d'erreur, et un lien direct vers le log d'exécution.

Pour mettre en place le workflow avec Error Trigger :

1. Créez un nouveau workflow et ajoutez le nœud Error Trigger comme nœud de départ. 2. Ajoutez l'étape d'alerte dont vous avez besoin — Slack, email, PagerDuty, ou un HTTP Request vers un webhook. 3. Enregistrez et publiez le workflow. 4. Dans vos workflows de production, ouvrez Settings et définissez « Error Workflow » sur ce gestionnaire.

Vous pouvez définir un gestionnaire d'erreurs global et le réutiliser sur tous les workflows de votre instance.

Envoyer des alertes lorsque quelque chose se casse

La chose la plus courante à faire dans un workflow d'erreur est d'envoyer une notification. Voici un exemple qui publie un message dans un canal Slack en utilisant les données de l'Error Trigger :

// Inside a Slack node's message field (using an expression)
`Workflow "{{ $json.workflow.name }}" failed.
Node: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
View execution: {{ $json.execution.url }}`

Si vous préférez utiliser le nœud HTTP Request pour appeler directement un webhook Slack :

{
  "text": "=Workflow \"{{ $json.workflow.name }}\" failed at node {{ $json.execution.lastNodeExecuted }}: {{ $json.execution.error.message }}"
}

Pour les alertes par email via le nœud Send Email, mappez les champs d'erreur dans le sujet et le corps de la même manière. L'essentiel est que chaque champ du payload de l'Error Trigger est accessible via la syntaxe d'expressions habituelle.

Vous pouvez également ajouter un nœud Set avant votre étape d'alerte pour remanier ou enrichir les données — par exemple en ajoutant un niveau de sévérité basé sur le nom du workflow, ou en ajoutant un timestamp.

Erreurs courantes

Pointer l'Error Workflow sur lui-même — si votre workflow gestionnaire d'erreurs échoue également, n8n ne le re-déclenchera pas récursivement, mais vous perdrez en visibilité. Gardez les workflows gestionnaires d'erreurs simples et avec peu de dépendances.

Oublier de publier le gestionnaire d'erreurs — un workflow défini comme Error Workflow doit être actif. S'il est enregistré en tant que brouillon, il ne s'exécutera pas.

Utiliser Continue on Error partout — cela peut masquer de vrais échecs. Réservez-le aux cas où vous avez une logique en aval explicite pour traiter l'élément en erreur. Ne l'utilisez pas comme un moyen de faire taire des erreurs que vous ne voulez pas traiter.

Ne pas tester le chemin d'erreur — créez un workflow de test avec un échec délibéré (un nœud HTTP Request pointant vers une URL qui renvoie un 500) et vérifiez que votre gestionnaire d'erreurs se déclenche réellement et envoie l'alerte attendue.

Résumé

Les paramètres au niveau du nœud vous permettent de contrôler le comportement en cas d'échecs individuels : arrêter, continuer, ou réessayer. Le nœud Error Trigger vous permet de construire un gestionnaire centralisé qui se déclenche dès qu'un workflow lié échoue, vous donnant le contexte d'exécution nécessaire pour envoyer une alerte pertinente. Ensemble, ces deux couches couvrent la grande majorité des besoins de gestion des erreurs en production dans n8n sans nécessiter de code personnalisé.