Je dois mieux commencer à surveiller les workflows.
Comment vous le faites, vous ?
@patriciaLee la réponse native que la plupart des gens oublient, c’est le Error Workflow, en configurer un globalement dans Settings et il s’active lors de n’importe quelle exécution échouée pour que tu puisses envoyer l’erreur vers slack/email/n’importe où sans avoir besoin de faire du polling. pour parcourir/auditer il y a la vue Executions avec des filtres de statut. et si tu es en self-hosted, configure N8N_METRICS=true pour exposer un endpoint /metrics prometheus que tu peux scraper dans grafana pour tes dashboards et tes alertes. error workflow + metrics couvre la plupart des setups en production.
Il y a deux catégories que j’évalue. La première catégorie est la santé de l’exécution. Je veux savoir si l’exécution a commencé, s’est terminée ou a rencontré une erreur. L’autre catégorie est le résultat commercial. Je dois déterminer si l’exécution a fait ce qu’elle était censée faire. Cette catégorie est plus difficile à évaluer. Par exemple, si une exécution a provoqué un filtre qui ignore tous les enregistrements, l’exécution serait réussie tout en étant complètement inutile.
Si un flux de travail est suffisamment important, j’enregistre plus de détails, notamment le nombre d’enregistrements traités, l’état final du flux de travail, la raison de l’échec du flux de travail, le propriétaire du flux de travail et l’étape suivante proposée.
En plus des erreurs, je surveille d’autres symptômes. Par exemple, si les flux de travail ne se sont pas terminés avec succès, si le nombre d’enregistrements traités tombe à 0, ou s’il y a un nombre croissant de tentatives de nouvelle tentative, je générerai une alerte. Je m’efforce toujours de rendre les alertes exploitables.
@patriciaLee a couvert l’essentiel (Error Workflow + vue Executions + Prometheus/Grafana) — c’est la bonne base. Deux choses que j’ajouterais pour couvrir ce que ceux-ci manquent :
-
Rendre l’Error Workflow vraiment exploitable. Une simple alerte « un workflow a échoué » ne suffit pas. Dans votre Error Workflow global, envoyez un message qui inclut le nom du workflow, l’URL de l’exécution, le nœud qui a échoué et le message d’erreur — cela transforme une chasse de 20 minutes en un seul clic pour accéder à l’exécution cassée. Définissez aussi EXECUTIONS_DATA_SAVE_ON_ERROR=all (et purgez les exécutions réussies avec les paramètres data-prune) pour conserver les exécutions échouées à déboguer sans surcharger la DB.
-
Surveiller les défaillances SILENCIEUSES — c’est le vrai point aveugle. Error Workflow + métriques ne se déclenchent que quand un workflow s’exécute et lance une erreur. Ils ne détectent PAS un workflow qui cesse silencieusement de s’exécuter — un trigger qui meurt, un webhook qui se désenregistre, une tâche cron qui s’arrête discrètement. C’est la défaillance qui fait vraiment mal, car vous l’apprenez des jours plus tard par le client. La solution est un dead-man’s switch : un trigger Schedule qui envoie une requête à un service de heartbeat (Healthchecks, Better Stack ou Uptime Kuma auto-hébergé) toutes les quelques minutes. Si la requête cesse d’arriver, cela vous alerte — vous détectez ainsi « ça a arrêté de s’exécuter du tout », pas seulement « ça s’est exécuté et a planté ».
Si vous êtes en auto-hébergé, j’ajouterais aussi un simple moniteur de disponibilité sur l’instance/conteneur n8n lui-même, pour savoir si tout est down vs. juste un workflow.
La configuration en couches que j’utiliserais : Error Workflow avec contexte enrichi pour les défaillances à l’exécution → Prometheus/Grafana pour la santé globale → un heartbeat/dead-man’s switch pour les arrêts silencieux → un moniteur de disponibilité sur l’instance. La plupart des gens configurent les deux premiers ; le heartbeat est celui que presque tout le monde oublie jusqu’à ce que ça leur retombe dessus.
Bon point de @ShawnWilliams pour distinguer l’intégrité de l’exécution du résultat commercial. Un exemple de la deuxième catégorie qui pourrait aider : j’ai construit un workflow quotidien qui ne surveille pas les erreurs, mais les opportunités de contenu, il parcourt les messages du forum et évalue via LLM s’ils sont pertinents pour moi, puis il envoie un résumé par mail.
Le point est : « Monitoring » ne doit pas seulement signifier erreurs. Tu peux utiliser le même mécanisme de workflow d’erreur pour aussi reconnaître les déclencheurs positifs, qu’il s’agisse de nouveaux leads, de contenus, ou simplement de questions ouvertes auxquelles tu peux répondre. La base technique (le setup d’Achamm) reste la même, seule la condition qui déclenche l’alerte change de « une erreur s’est produite » à « un événement intéressant détecté ».
@patriciaLee et d’autres ont couvert les éléments essentiels (Error Workflow, vue Executions, Prometheus/Grafana, et la distinction entre la santé de l’exécution et les résultats métier). J’ajouterais une couche supplémentaire qui m’a causé des problèmes en production : les défaillances silencieuses.
Les Error Workflows et les métriques ne servent que lorsqu’une action s’exécute réellement et génère une erreur. Ils ne détectent pas un déclencheur qui cesse de fonctionner, un abonnement webhook qui expire silencieusement (les Gmail watches en sont un exemple classique), ou une tâche cron qui ne s’exécute jamais. Rien ne s’exécute, donc rien n’est observé. À mon expérience, ce sont souvent les défaillances les plus douloureuses car vous les découvrez par un client plutôt que par la surveillance.
L’approche que j’ai adoptée est un dead-man’s switch : un workflow planifié envoie un ping à un service de heartbeat (Healthchecks.io, Better Stack, ou Uptime Kuma auto-hébergé). Si le heartbeat cesse d’arriver, c’est l’alerte. Cela complète les Error Workflows en détectant « ça a arrêté de s’exécuter entièrement », pas seulement « ça s’est exécuté et a échoué ».
J’aime aussi le point de Shawn sur les résultats métier. Pour les workflows importants, je suivi des choses comme les enregistrements traités, les nombres de tentatives, les volumes minimaux attendus et la responsabilité. Un workflow qui traite avec succès zéro enregistrement peut être techniquement sain mais opérationnellement inutile, donc ces métriques méritent aussi des alertes.
Le modèle en couches qui a bien fonctionné pour moi est :
- Error Workflow → contexte riche (workflow, nœud, URL d’exécution, détails d’erreur)
- Prometheus/Grafana → métriques agrégées et tendances
- Métriques métier → enregistrements traités, tentatives, résultats attendus
- Heartbeat/dead-man’s switch → défaillances silencieuses
- Monitoring de disponibilité → santé instance/conteneur
La plupart des gens implémentent les deux premières couches. Les couches heartbeat et résultats métier sont celles qui tendent à vous sauver des mauvaises surprises plus tard.
La division de Shawn est celle que j’utiliserais : santé d’exécution vs résultat commercial.
Pour les workflows clients, j’ajouterais un petit reçu d’exécution à l’alerte : fenêtre attendue, enregistrements traités, compte/identifiant utilisé, action en aval tentée, ID final du dossier/message, et qui est responsable de l’étape suivante. L’exécution verte est moins utile que la preuve de ce qui a changé.
Ce thread couvre déjà bien les points importants : la distinction entre la santé d’exécution et le fait que le résultat s’est réellement produit, ainsi que l’idée du heartbeat pour la exécution qui ne se déclenche jamais. Je vais donc simplement ajouter la seule défaillance qui passe encore à travers tout cela. Même avec une vérification du nombre d’enregistrements et un mécanisme de sécurité en place, le cas qui pose problème est l’exécution qui se termine, traite son nombre habituel de lignes, ne lève rien, et reste quand même incorrecte, parce qu’une credential a silencieusement expiré ou une source est devenue obsolète et l’API a renvoyé une réponse valide mais vide ou générique. Le nombre semble normal, le statut est vert, rien ne génère d’erreur, donc aucune des couches au-dessus ne le signale.
La raison pour laquelle un Error Trigger standard est aveugle à cela est qu’il n’y a eu aucune erreur. Le token ne s’est pas échoué bruyamment, il a renvoyé un 200 propre avec rien d’utile dedans, et le workflow l’a joyeusement transmis. Une alerte de nombre d’enregistrements le manque aussi, parce que le nombre peut être normal alors que le contenu est obsolète ou vide.
Ce qui le détecte sans grand effort c’est de vérifier le contenu, pas seulement sa présence. Après tout appel sensible à l’authentification, assertez sur un champ qui n’apparaît que lorsque l’appel a genuinely réussi, plutôt que de simplement vérifier que la réponse est non vide, et ajoutez une vérification de fraîcheur : le nouvel enregistrement est-il vraiment récent ou est-ce que j’observe les données d’hier qu’on me renvoie. Pour l’angle des credentials spécifiquement, il aide de traiter un résultat vide inattendu d’une source normalement active comme une condition d’échec plutôt que comme un succès silencieux.
L’état d’esprit qui lie tout ce thread ensemble : une exécution verte avec un nombre de lignes normal n’est toujours pas la preuve que les données sont réelles, seulement que quelque chose est revenu. La vérification qu’il vaut la peine d’ajouter est de savoir si le résultat est frais et correct, pas seulement présent. Que faites-vous tous face au cas obsolète-mais-vert, ou ne vous a-t-il pas encore posé problème ?
Ce fil de discussion couvre bien les couches essentielles : gestion des erreurs avec contexte, Prometheus/Grafana, heartbeat pour les défaillances silencieuses, et le cas « vert mais obsolète » que quelqu’un a soulevé. Une lacune que j’ajouterais, surtout si vous ne faites pas tourner n8n en isolation :
Tout ce qui a été mentionné jusqu’à présent est natif à n8n. Error Workflow, N8N_METRICS, la vue Executions. C’est le bon choix si n8n est votre seule surface d’automatisation. Mais beaucoup d’équipes ne sont pas purement n8n. Elles ont des scénarios Make, quelques zaps Zapier, un cron job, peut-être un script ou deux, tout cela effectuant du vrai travail en production. Chacun a son propre dashboard, donc « est-ce que tout est sain » signifie vérifier trois ou quatre endroits différents, et le pattern heartbeat que les gens ont décrit ici doit être reconstruit séparément pour chaque outil.
Le pattern qui a fonctionné pour moi : traiter « est-ce que ça a tourné, est-ce que ça a réussi, est-ce que ça a échoué » comme un simple événement qu’on envoie d’où que vive l’automatisation. Un appel HTTP depuis les chemins success et error de n8n, la même chose depuis un webhook Make ou un webhook Zapier ou un try/except dans un script, tout atterrissant au même endroit qui ne se soucie pas quel outil l’a envoyé. La même idée de heartbeat que ci-dessus, juste pas verrouillée à une seule plateforme.
Disclaimer puisque je dois le dire clairement : j’ai construit un outil pour exactement ça (FlowPulse) après avoir rencontré moi-même ce même problème « quatre dashboards, pas de vue unique ». Je n’essaye pas de vendre quelque chose au milieu d’une bonne discussion, juste de signaler que c’est là au cas où la partie multi-plateforme serait utile à quelqu’un. Je serais heureux de discuter aussi de la version DIY si c’est plus votre style.