Comment surveiller les erreurs des automatisations n8n ?
Un processus de gestion des erreurs peut envoyer une alerte lorsqu’une exécution automatique échoue ; la liste des exécutions aide ensuite à enquêter. Ce sont des moyens complémentaires dans n8n, que nous utilisons pour automatiser. Ils ne prouvent pas à eux seuls que chaque tâche attendue a démarré et produit le bon résultat métier.
Comment configurer un processus de gestion des erreurs ?
Créez un processus dont le premier nœud est Error Trigger, puis ajoutez les actions de notification, par exemple un courriel ou Slack. Enregistrez-le. Dans le processus surveillé, ouvrez Options → Settings, sélectionnez-le dans Error workflow et enregistrez ce réglage. La documentation permet d’utiliser le même gestionnaire pour plusieurs processus.
Ajouter le nœud ne configure pas automatiquement les destinataires, les accès et l’envoi. Vérifiez le parcours de l’alerte avec une exécution automatique contrôlée. Selon la documentation, Error Trigger ne réagit pas aux exécutions manuelles dans l’éditeur ; le processus de gestion des erreurs lui-même n’a pas besoin d’être publié.
Quelles données reçoit Error Trigger ?
Les données décrivent le processus et l’erreur : nom, identifiant, message, trace technique et dernier nœud exécuté selon le cas. L’identifiant et l’adresse de l’exécution dépendent de son enregistrement dans la base. En cas d’erreur du nœud déclencheur, ils peuvent manquer et laisser place à davantage d’informations sur le déclencheur.
Ne supposez pas que toutes les alertes contiennent les mêmes champs. Prévoyez les différents cas. Les données d’erreur peuvent contenir des informations de l’entreprise ; définissez qui reçoit quoi plutôt que de transmettre systématiquement l’enregistrement intégral.
À quoi sert la liste des exécutions ?
Dans Overview → Executions, filtrez par processus, période et statut : Failed, Running, Success ou Waiting. Les accès aux projets et les réglages influent sur ce qui est visible. Ce n’est pas une archive permanente de tous les lancements : des règles d’enregistrement et de suppression des anciennes données s’appliquent.
Lorsque la fonction et les droits le permettent, Debug in editor charge les données d’un échec pour l’examiner. Relancer peut répéter une action externe. Vérifiez ce qui a déjà été enregistré ou envoyé et comment éviter les doublons avant une nouvelle exécution.
Comment combiner alertes et examen régulier ?
L’alerte signale un échec précis ; l’examen périodique peut révéler une récurrence. Comparez aussi les exécutions attendues et réelles. Une tâche qui n’a jamais démarré n’est pas une exécution portant le statut Failed.
Un succès technique ne prouve ni une facture correcte ni le traitement de tous les enregistrements attendus. Définissez le résultat vérifié selon l’inventaire. n8n propose Stop And Error pour une condition choisie, mais cette condition doit être définie ; le logiciel ne devine pas l’erreur métier.
Que devient l’historique d’un processus supprimé ?
La documentation précise que la suppression retire aussi son historique d’exécution. Avant de reconstruire, établissez les données nécessaires aux vérifications futures et assurez-vous qu’elles sont encore conservées. Exporter la définition du processus n’exporte pas automatiquement son historique.
Convenez de la conservation nécessaire, des accès et du traitement des données sensibles avant suppression. L’absence d’un enregistrement ne prouve pas qu’un processus n’a jamais été exécuté.
Questions
Faut-il un gestionnaire distinct pour chaque automatisation ?
Non. Le même processus Error Trigger peut être choisi pour plusieurs automatisations. Configurez les données et destinataires qui conviennent à chacune.
Que se passe-t-il sans processus de gestion des erreurs sélectionné ?
Si le processus contient Error Trigger, la documentation indique qu’il s’utilise lui-même par défaut. Sinon, vérifiez les réglages d’enregistrement et les autres canaux de surveillance. Ne supposez pas que chaque erreur restera visible ou enverra automatiquement un courriel.
La liste établit-elle la cause première ?
Elle montre les données disponibles et peut désigner le nœud où l’échec a été détecté. Ce n’est pas toujours la cause première. Examinez les entrées, services externes et actions accomplies selon le cas.
Sources
Pour poursuivre
Étape suivante
Vérifiez les exécutions et la transmission des alertes.
Notre surveillance contrôle les exécutions dans l’inventaire convenu et associe alertes et examen des enregistrements. Nous précisons les destinataires nommés et vérifions la transmission. Cela ne prouve pas une lecture humaine immédiate ; les contrôles d’exécutions attendues mais absentes doivent aussi être définis dans le périmètre.
ou écrivez à contact@ergostrat.com