n8n : recevoir une alerte quand un workflow échoue

Que préparer pour ce tutoriel n8n Error Trigger ?

Il vous faut un accès n8n permettant de créer des scénarios et un moyen d’envoyer un message vers une destination que vous contrôlez. Le parcours ci-dessous utilise un e-mail ; il nécessite une connexion SMTP (serveur d’envoi des e-mails) autorisée, avec les paramètres fournis par votre messagerie.

Si vous découvrez encore les branchements, commencez par notre première automatisation n8n avec données fictives. Ici, nous construisons deux scénarios distincts :

Les noms de nœuds sont ceux de la documentation actuelle, consultée le 11 octobre 2026. Leur emplacement peut varier selon votre version. Ce guide fournit une procédure à tester dans votre instance : il ne présente pas le résultat d’une exécution n8n réalisée par DataSuits.

Comment relier l’alerte au scénario surveillé ?

Créez d’abord Alerte_Erreur avec Error Trigger en première étape, puis enregistrez-le. Dans TEST_Panne, ouvrez les options du workflow, puis Settings ; choisissez Alerte_Erreur dans Error workflow et enregistrez ce réglage.

La documentation n8n sur le gestionnaire d’erreur décrit cette association. Un même gestionnaire peut servir à plusieurs scénarios, mais ils doivent chacun lui être reliés.

Le gestionnaire démarré par Error Trigger n’a pas besoin d’être publié séparément pour remplir ce rôle. En revanche, le scénario de test planifié doit être enregistré et publié pour son déclenchement automatique. Gardez ces deux rôles distincts : créer une alerte ne met pas automatiquement votre scénario métier en service.

Quelles informations mettre dans une alerte utile ?

Gardez de quoi identifier le traitement et ouvrir son historique. Évitez de transférer le dossier d’entrée, les pièces jointes ou la trace technique complète dans un e-mail. Pour commencer, un nom de scénario, une étape, une référence et une consigne suffisent.

Après Error Trigger, ajoutez Edit Fields (Set). En mode Manual Mapping, créez ces quatre champs de type String, c’est-à-dire texte. Passez chaque valeur en mode Expression et saisissez l’expression correspondante :

{{ $json.workflow?.name || "Workflow à identifier" }}

{{ $json.execution?.lastNodeExecuted || "Déclencheur ou étape non précisée" }}

{{ $json.execution?.id || "Non disponible" }}

{{ $json.execution?.url || "" }}

$json désigne les données reçues par cette étape. Le signe ?. permet de lire un champ sans provoquer une erreur quand l’objet manque ; || choisit ici un texte de remplacement si la valeur est absente ou vide.

Dans Edit Fields, conservez uniquement les champs que vous venez de définir : la documentation présente notamment le réglage Keep Only Set Fields. Vérifiez la sortie affichée : elle doit contenir ces quatre champs et aucun contenu brut de l’erreur. N’incluez pas les données binaires. Le passage entre valeur fixe et expression est expliqué dans la documentation des expressions. Les réglages sont détaillés dans la fiche Edit Fields.

Selon le type d’échec et la sauvegarde de l’exécution, la référence et le lien peuvent manquer. Une erreur au déclenchement ne fournit pas nécessairement le même objet qu’une panne à une étape suivante. Ce cas est décrit dans les données reçues par Error Trigger. Ne rendez pas le lien obligatoire pour envoyer l’alerte.

Reliez ensuite Send Email. Configurez la connexion, l’expéditeur et votre propre adresse de test. Choisissez Operation : Send et Email Format : Text. Passez l’objet et le corps en mode Expression avant de coller les modèles. Exemple d’objet : Échec n8n — {{ $json.processus }}. Pour le corps :

Le traitement {{ $json.processus }} a échoué.
Étape : {{ $json.etape }}
Référence : {{ $json.reference }}
Lien, si disponible : {{ $json.lien }}

À faire : consulter l’historique et vérifier les actions déjà réalisées avant de relancer.

La fiche officielle Send Email détaille la connexion d’envoi et les formats de message. Testez la réception avec votre messagerie : les droits, les paramètres de connexion et les filtres de réception restent propres à votre compte.

Donnez aux scénarios et aux étapes des noms neutres : ne mettez pas de nom de client ou de secret dans leur libellé. Le lien vers l’historique reste destiné à une personne autorisée à ouvrir votre instance n8n ; il ne remplace pas ses droits d’accès.

Comment provoquer une erreur pour tester la réception ?

Utilisez TEST_Panne, sans action réelle autre que l’envoi de votre alerte de test. Ajoutez Schedule Trigger puis Stop And Error. Dans ce dernier, vérifiez que On Error est réglé sur Stop Workflow, puis choisissez Error Message et saisissez TEST_ALERTE — échec volontaire sans donnée réelle.

Le nœud Stop And Error force un échec avec le message choisi. Cela vous évite de casser volontairement une vraie connexion ou de modifier un dossier de production.

Enregistrez Alerte_Erreur après avoir configuré toutes ses étapes. Pour retrouver les traces du test, choisissez Save failed production executions dans TEST_Panne et Save successful production executions dans Alerte_Erreur, avec la valeur qui enregistre ces exécutions. Ces choix sont décrits dans les réglages des workflows.

1. Préparer une courte fenêtre de testDans Schedule Trigger, choisissez un intervalle en minutes, par exemple une minute. Vérifiez le fuseau du workflow et l’association avec Alerte_Erreur.
2. Laisser démarrer automatiquementEnregistrez et publiez TEST_Panne. Attendez un déclenchement planifié au lieu de cliquer seulement sur Execute Workflow. Le scénario doit échouer sur Stop And Error.
3. Vérifier toute la chaîneRetrouvez l’échec dans l’historique de TEST_Panne, l’exécution d’Alerte_Erreur et le message effectivement reçu. S’il existe un lien dans l’alerte, ouvrez-le avec votre compte autorisé.
4. Arrêter le testRetirez TEST_Panne de la publication pour arrêter ses déclenchements automatiques. Un test laissé toutes les minutes continuerait à produire des erreurs et des messages inutiles.

Schedule Trigger nécessite un workflow publié et utilise les réglages de fuseau. La documentation d’Error Trigger précise, elle, qu’un lancement manuel du scénario surveillé ne teste pas son déclenchement automatique d’erreur.

Vous pouvez tester séparément la construction du texte avec des données fictives. Cela vérifie le format, mais pas l’association entre workflows ni la réception réelle. Ce sont trois contrôles différents.

Après ce contrôle, sélectionnez Alerte_Erreur dans les réglages du scénario que vous souhaitez réellement surveiller, puis enregistrez l’association. Le test isolé ne valide pas encore les particularités de ce scénario.

Exercice : faut-il relancer dans ces quatre situations ?

Lisez les faits disponibles avant de décider. Les quatre situations suivantes sont fictives ; aucune ne représente un incident de DataSuits. Pour chacune, choisissez votre prochaine action et ce qu’il reste à vérifier.

Pour approfondir le cas B, reprenez notre méthode pour éviter les créations en double lors d’une reprise. Ce guide d’alerte ne met en place aucune relance automatique.

Qu’est-ce qu’une alerte d’erreur ne surveille pas ?

Elle signale un échec que votre instance peut détecter et transmettre par le gestionnaire associé. Elle ne garantit pas que chaque résultat métier est correct. Un scénario peut terminer sans erreur technique tout en produisant une information inutile.

Une erreur qu’un nœud laisse passer ne fait pas forcément échouer le scénario. Avec On Error réglé sur Continue ou Continue (using error output), le traitement peut continuer sans déclencher ce gestionnaire. La documentation des réglages des nœuds distingue ces choix. Notre test utilise Stop Workflow afin de provoquer un véritable échec.

Par exemple, recevoir zéro demande alors que vous attendiez un export peut demander un contrôle métier distinct. Définissez ce qui est normal avant de transformer toute absence en panne : certains jours, zéro demande peut être le bon résultat.

Le canal d’alerte peut aussi tomber en panne. Si n8n ne fonctionne plus ou si la messagerie n’envoie plus, une chaîne construite dans ces mêmes outils ne suffit pas à garantir une notification. Pour un traitement important, prévoyez un contrôle indépendant du résultat attendu et de son heure d’arrivée.

Je vous recommande d’écrire une fiche courte : résultat attendu, heure de contrôle, personne responsable et action en cas d’absence. Une alerte sans destinataire qui sait quoi faire reste un message de plus.

Ces cases restent locales à cette page et se réinitialisent au rechargement. Si vous ajoutez ensuite une étape IA, complétez le contrôle technique par un jeu de tests pour le prompt : un texte reçu n’est pas forcément un texte juste.

Questions fréquentes sur les alertes n8n

Faut-il un gestionnaire différent pour chaque scénario ?

Pas nécessairement. Vous pouvez réutiliser le même et relier les scénarios concernés. Gardez toutefois un destinataire et une consigne adaptés à leur importance.

Faut-il envoyer le message d’erreur complet par e-mail ?

Pas pour ce premier montage. Le message proposé oriente vers l’historique autorisé. Examinez le diagnostic dans n8n avant de décider quelles informations techniques peuvent être partagées.

Une alerte autorise-t-elle une relance automatique ?

Non. Elle indique qu’une vérification est nécessaire. Les actions déjà confirmées, celles qui ont échoué et celles dont le résultat est incertain ne se reprennent pas de la même manière.