Erreurs n8n : retry et Error Trigger

Un workflow peut tourner sans problème pendant trois semaines, puis rester en erreur depuis mardi sans prévenir personne. Une API renvoie un timeout, un champ vide fait planter un nœud et les données n’arrivent plus dans votre CRM. Vous découvrez le problème plusieurs jours plus tard, sans savoir quand il a commencé.

Ce scénario, je l’ai vu des dizaines de fois en accompagnant des gens sur n8n . Et 9 fois sur 10, le problème n’est pas le workflow en lui-même. Le problème, c’est qu’il a été construit en supposant que tout se passerait toujours bien. Or en production, ça ne se passe jamais toujours bien.

Dans ce guide je vais vous montrer comment construire des workflows qui encaissent. Pas en théorie : on va s’appuyer sur un vrai workflow que j’utilise dans ma formation, avec son service qui plante volontairement, pour voir chaque mécanisme à l’œuvre. À la fin vous saurez exactement quel outil sortir selon le type d’erreur, et vous aurez un filet de sécurité qui vous prévient avant que le client ne le fasse.

La première chose à comprendre : toutes les erreurs ne se valent pas

C’est l’erreur de débutant la plus courante, et elle conditionne tout le reste. On a tendance à traiter « une erreur » comme un bloc unique, alors qu’il y a en réalité trois familles distinctes, et chacune appelle une réponse différente.

Type d’erreur	Exemple concret	La bonne réponse
Transitoire	Timeout réseau, rate-limit d’une API, service momentanément down	Réessayer (retry) : ça va probablement marcher au 2ᵉ coup
Métier (prévue)	Stock à zéro, paiement refusé, email invalide	Dévier : une branche de secours qui traite le cas proprement
Imprévue	Bug dans une expression, credential expiré, cas jamais anticipé	Alerter : un filet de sécurité global qui vous prévient

Gardez cette grille en tête, parce que les trois mécanismes qu’on va voir y répondent un par un. Le retry pour le transitoire. L’error output pour le métier. L’Error Trigger pour l’imprévu. Mélanger les trois, ou n’en utiliser qu’un seul pour tout, c’est exactement ce qui crée les workflows fragiles.

Le cas qu’on va dérouler : un contrôle de stock avant expédition

Pour rendre tout ça concret, je prends un workflow de mon parcours n8n, un fil rouge e-commerce que j’appelle ShopFlow. L’étape qui nous intéresse fait une chose simple : avant d’expédier une commande, elle vérifie le stock auprès d’un service interne, puis bloque les articles en rupture.

Trois commandes passent dans le flux :

return [
  { json: { id: 'CMD-201', produit: 'Clavier', sku: 'KB-01', stock_dispo: 12 } },
  { json: { id: 'CMD-202', produit: 'Souris',  sku: 'MS-02', stock_dispo: 0  } },
  { json: { id: 'CMD-203', produit: 'Écran',   sku: 'SC-03', stock_dispo: 3  } }
];

Et là où ça devient intéressant, c’est que j’ai rendu le service de stock volontairement instable. Une fois sur deux et quelques, il échoue avec un timeout :

// Service de stock INSTABLE : il échoue parfois (timeout transitoire).
if (Math.random() < 0.6) {
  throw new Error('Timeout service stock (transitoire)');
}
// Si on passe, l'appel a réussi (éventuellement après 1-2 retries)
const a = $json;
return { json: Object.assign({}, a, { stock_verifie: true }) };

On a donc nos deux premiers types d’erreurs réunis dans un seul workflow. Le timeout du service, c’est du transitoire. La Souris à stock_dispo: 0, c’est du métier. Voyons comment n8n traite chacun.

Mécanisme 1 : le retry automatique pour les erreurs transitoires

Quand un nœud appelle une API ou un service réseau, l’échec ponctuel fait partie de la vie. Le réseau hoquette, le serveur d’en face est surchargé une seconde, et l’appel d’après serait passé sans problème. C’est exactement le cas où vous ne voulez pas que votre workflow s’arrête. Vous voulez qu’il réessaie.

n8n a ça intégré dans chaque nœud. Vous ouvrez le nœud, onglet Settings, et vous trouvez trois réglages.

Réglage (onglet Settings)	Ce qu’il fait	Valeur conseillée
Retry On Fail	Active les tentatives automatiques en cas d’échec	Activé sur les nœuds réseau
Max. Tries	Nombre total de tentatives avant d’abandonner	2 à 3 suffisent presque toujours
Wait Between Tries (ms)	Délai d’attente entre deux tentatives	1000 à 2000 ms

Sur mon nœud Vérifier stock, la config ressemble à ça côté JSON (ce que vous obtenez si vous exportez le workflow) :

{
  "retryOnFail": true,
  "maxTries": 3,
  "waitBetweenTries": 1000
}

Concrètement : le service échoue, n8n attend une seconde, réessaie. S’il échoue encore, il attend de nouveau et retente. Au bout de 3 essais ratés, il abandonne et le nœud passe en erreur. Avec un taux d’échec de 60% sur mon service de démo, le calcul est vite fait : la probabilité que les trois tentatives ratent d’affilée tombe autour de 20%. Le retry transforme donc un workflow qui plante une fois sur deux en un workflow qui passe quatre fois sur cinq.

Petite limite bonne à connaître : les réglages natifs plafonnent à 5 tentatives et un délai max de 5000 ms par nœud. Pour la grande majorité des cas, c’est largement suffisant. Si vous avez besoin de plus, ou d’un délai qui augmente à chaque essai, il y a une technique maison qu’on verra en fin de guide.

Le piège qui fait perdre des heures : retry + On Error ensemble

Voilà un truc que personne ne vous dit et qui crée une confusion totale quand vous débutez. Si vous activez Retry On Fail sur un nœud, et que dans le même temps vous mettez On Error sur une des options « Continue », alors vos réglages Max. Tries et Wait Between Tries sont purement et simplement ignorés.

Le nœud n’essaie qu’une fois, échoue, et part directement sur la sortie d’erreur. Pas de retry du tout. Le retry n’agit que si On Error est resté sur Stop Workflow.

C’est précisément pour ça que dans ShopFlow le retry et la branche de secours sont sur deux nœuds distincts. Le nœud Vérifier stock porte le retry (erreur transitoire). Le nœud Contrôle rupture qui suit porte l’error output (erreur métier). Chacun son job.

Mécanisme 2 : l’error output pour les erreurs métier

La rupture de stock, ce n’est pas un bug. C’est un cas business parfaitement normal qui va arriver tous les jours. Vous ne voulez donc surtout pas réessayer (le stock ne va pas réapparaître en réessayant), et vous ne voulez pas non plus que ça casse le traitement des deux autres commandes. Vous voulez dévier cette commande vers un traitement spécifique : la mettre en attente de réapprovisionnement.

Pour ça, le réglage On Error du nœud (toujours dans l’onglet Settings) propose trois comportements.

Option « On Error »	Comportement	Quand l’utiliser
Stop Workflow (défaut)	L’erreur arrête tout le workflow	Erreur grave qui doit tout bloquer
Continue (using regular output)	Le nœud continue, l’item fautif passe quand même	Erreur que vous pouvez ignorer sans conséquence
Continue (using error output)	Une 2ᵉ sortie « erreur » s’ouvre, les items fautifs y partent	Erreur métier que vous voulez traiter à part

C’est la troisième option qui nous intéresse. Quand vous la choisissez, le nœud affiche deux sorties : la sortie normale (les items qui ont réussi) et une sortie rouge « erreur » (les items qui ont échoué). Vous branchez chaque sortie où vous voulez.

Dans mon nœud Contrôle rupture, je lève une erreur explicite si le stock est insuffisant :

const a = $json;
if (a.stock_dispo < 1) {
  throw new Error('Rupture de stock sur ' + a.sku + ' (' + a.produit + ')');
}
return { json: Object.assign({}, a, { statut_stock: 'disponible' }) };

Et côté config, le nœud est réglé sur :

{ "onError": "continueErrorOutput" }

Résultat sur mes trois commandes :

CMD-201 (Clavier, stock 12) part sur la sortie normale, direction Préparer expédition.
CMD-203 (Écran, stock 3) pareil, expédition préparée.
CMD-202 (Souris, stock 0) lève l’erreur, part sur la sortie d’erreur, direction Mise en attente de réappro.

La commande en rupture est traitée proprement, et les deux autres ne sont pas impactées. C’est ça, la différence entre un workflow qui plante au premier grain de sable et un workflow qui encaisse.

Mécanisme 3 : l’Error Trigger, votre filet de sécurité global

On a couvert le transitoire et le métier. Reste le plus sournois : l’erreur que vous n’avez pas prévue. Le retry qui a épuisé ses 3 tentatives. Le credential qui a expiré pendant la nuit. L’API qui a changé son format de réponse. Le cas auquel vous n’aviez tout simplement pas pensé en construisant le workflow.

Par définition, vous ne pouvez pas mettre une branche de secours sur un cas que vous n’avez pas anticipé. C’est là qu’intervient l’Error Trigger, et c’est le mécanisme que je vois le moins utilisé alors que c’est le plus important des trois.

Le principe : vous créez un workflow séparé, dédié, dont le tout premier nœud est un Error Trigger. Ce workflow ne fait rien de métier. Son seul rôle, c’est de se déclencher automatiquement à chaque fois qu’un autre workflow plante sans avoir rattrapé l’erreur.

Voici comment le brancher, en trois étapes :

Créez un nouveau workflow et posez un nœud Error Trigger comme déclencheur. Ne mettez rien d’autre pour l’instant.
Branchez derrière une notification : un nœud Slack ou Gmail qui vous envoie les détails. L’Error Trigger fournit automatiquement le nom du workflow en faute, le nœud où ça a cassé, et le message d’erreur.
Désignez ce workflow comme filet : dans les Settings de chacun de vos workflows de production, il y a un champ Error Workflow. Vous y sélectionnez votre workflow d’alerte. À partir de là, dès qu’une erreur non rattrapée survient, votre alerte se déclenche.

Un exemple de message Slack que vous pouvez composer avec les données de l’Error Trigger :

🔴 Workflow en erreur : {{ $json.workflow.name }}
Nœud fautif : {{ $json.execution.lastNodeExecuted }}
Message : {{ $json.execution.error.message }}
Heure : {{ $json.execution.startedAt }}

À partir de ce moment, vous ne découvrez plus vos pannes trois jours trop tard. Vous recevez un ping en temps réel, avec assez de contexte pour savoir où regarder. Et vous pouvez brancher un seul workflow d’alerte comme filet pour toute votre instance : un seul Error Workflow protège des dizaines de workflows de prod.

Pour aller plus loin : le backoff exponentiel maison

Je vous parlais du plafond de 5 tentatives et 5000 ms sur le retry natif. Dans 95% des cas vous n’en avez pas besoin. Mais si vous tapez une API qui rate-limit agressivement (certaines APIs vous bannissent temporairement si vous insistez trop vite), la bonne pratique est le backoff exponentiel : attendre 1 seconde, puis 2, puis 4, puis 8. Chaque échec double le délai, ce qui laisse le service respirer.

Le retry natif ne fait pas ça (son délai est fixe). Mais vous pouvez le reconstruire à la main avec trois nœuds : un Set pour stocker le compteur de tentatives, un IF pour vérifier si vous avez atteint la limite, et un Wait dont la durée est calculée par une expression du genre {{ 2 ** $json.tentative * 1000 }}. Vous bouclez tant que l’appel échoue et que le compteur n’a pas atteint votre maximum.

C’est plus de travail à câbler, donc réservez cette technique aux cas où le retry natif ne suffit vraiment pas. Pour 9 workflows sur 10, Retry On Fail avec 3 tentatives fait parfaitement le boulot.

Votre checklist robustesse, à appliquer sur chaque workflow de prod

Avant de mettre un workflow en production, passez-le au crible de ces questions. C’est exactement la grille que j’utilise pour mes propres automatisations clients.

Question	Si la réponse est non
Mes nœuds réseau (HTTP, API) ont-ils Retry On Fail activé ?	Activez-le avec Max. Tries = 3
Mes cas métier connus ont-ils une branche de secours (error output) ?	Ajoutez un onError + traitement dédié
Ai-je un workflow Error Trigger branché comme Error Workflow ?	Créez-le, c’est votre priorité numéro 1
Suis-je notifié quand un workflow plante (Slack, email) ?	Branchez la notif derrière l’Error Trigger
Ai-je vérifié que retry et error output ne sont pas sur le même nœud ?	Séparez-les sur deux nœuds distincts

Si vous cochez ces cinq cases sur chacun de vos workflows, vous êtes déjà au-dessus de l’immense majorité des automatisations que je vois passer. La robustesse, ce n’est pas un sujet avancé réservé aux experts. C’est cinq réflexes que vous prenez dès le départ, et qui vous font gagner un temps fou en SAV.

En résumé

La gestion des erreurs dans n8n tient en trois outils, un par type d’erreur. Le retry (Retry On Fail / Max. Tries / Wait Between Tries) pour les pannes transitoires de réseau. L’error output (On Error → Continue using error output) pour les cas métier que vous voulez dévier sans tout casser. L’Error Trigger branché en Error Workflow pour être alerté de tout ce que vous n’avez pas vu venir.

Le piège à éviter : ne mettez jamais le retry et l’error output sur le même nœud, sinon le retry est ignoré. Séparez les responsabilités, comme dans le workflow ShopFlow qu’on a déroulé, et chaque mécanisme fait son travail.

Si vous voulez construire ce genre de workflows pas à pas, avec les exercices ShopFlow complets, c’est exactement ce que je couvre dans ma formation n8n. On part de zéro pour vous rendre autonome sur vos propres opérations.

Et pour creuser le détail de chaque réglage, la doc officielle n8n sur l’error handling est la référence à garder sous le coude.

Gérer les erreurs dans n8n : retry, error output et Error Trigger