Décrivez le problème/l’erreur/la question
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Partagez la sortie retournée par le dernier nœud
Informations sur votre configuration n8n
- Version de n8n :
- Base de données (par défaut : SQLite) :
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
- Système d’exploitation :
@moneywithjjcom Bonjour, bienvenue !
Le vrai problème ici est la fatigue des alertes causée par des vérifications de données rigides qui ne tiennent pas compte de la façon dont les données changent réellement au fil du temps.
Quand vous gardez un workflow n8n en cours d’exécution pendant des mois, les vérifications simples s’effondrent pour trois raisons
. Traiter toutes les données manquantes de la même façon
. ne pas vérifier la fenêtre de rétroaction
Finalement devenir du bruit de fond
En bref, le problème est de construire des vérifications « bêtes » qui ne comprennent pas le contexte ou les limites des données historiques, ce qui transforme finalement un outil utile en bruit ignoré
@moneywithjjcom veuillez partager votre écran, pour que je puisse mieux vous aider
Je ne peux pas répondre honnêtement à ta question — nos vérifications sont structurelles plutôt que au niveau du contenu (ça a-t-il fonctionné, ça a-t-il échoué, répond-il toujours), et nous ne lisons délibérément jamais les données d’exécution, donc je n’ai pas d’histoire au quatrième mois sur une liste de valeurs qui se dégrade. Ce qui suit est la même maladie une couche plus bas, où nous avons dû changer quelque chose.
La version brute de ta dégradation nous est arrivée la semaine dernière. La vérification inatteignable s’est déclenchée sur un seul sondage échoué : une requête expirée, un email, l’instance allait bien tout le temps. Vérification correcte, alerte correcte, et après la deuxième tu arrêtes de les lire — ton opérateur de relevé bancaire exactement, juste avec un prédicat plus bête. Le correctif n’était pas un meilleur délai d’attente, c’était d’arrêter de traiter une observation comme un état : une panne est maintenant deux défaillances consécutives, avec l’intervalle augmentant après chacune. Le nombre 2 n’est pas l’insight ; accepter qu’une lecture unique n’est pas une preuve l’est.
« Une vérification doit pouvoir refuser de répondre » est la ligne la plus nette de ce post et elle se généralise au-delà du contenu. Deux endroits où nous l’avons trouvée nécessaire :
- Premier contact. La première passe sur une instance nouvellement connectée lit l’historique auquel nous n’avons pas assisté. Alerter sur cela produit une inondation de défaillances qui ont déjà eu lieu et ont déjà été traitées, ce qui est le chemin le plus rapide vers être réduit au silence — le premier jour. Donc la première passe enregistre et reste silencieuse. Même règle que la tienne : une fenêtre que tu n’as pas observée n’est pas une preuve de quoi que ce soit.
- Cadence. Ton cas intermédiaire, réel mais pas par exécution, a un jumeau structurel : un flux de travail mensuel semble bloqué à quoi que ce soit qui vérifie quotidiennement. Le correctif évident est de laisser l’opérateur déclarer un intervalle attendu par flux de travail, et c’est la version qui se dégrade — la liste devient obsolète exactement de la même façon que sa liste de valeurs, et elle devient obsolète silencieusement quand quelqu’un ajoute un flux de travail et ne te le dit pas. Dériver l’intervalle du déclencheur de planification du flux de travail lui-même était la seule version que nous avons trouvée qui survit à être ignorée.
Une chose à ajouter à ta taxonomie plutôt que de la contredire. Les trois états que tu décris supposent que la vérification a fonctionné. Il y en a un quatrième assis dessous — la vérification n’a pas du tout été exécutée — et à l’intérieur de n8n elle est invisible, parce qu’une vérification qui vit dans l’instance s’arrête quand l’instance s’arrête, et son silence a exactement la même forme que tout va bien. L’alarme réduite au silence de ton opérateur a au moins encore produit une ligne qu’il a choisi d’ignorer. Celle-ci ne produit rien, et rien est ce que la réussite ressemble.
Ce n’est pas un problème de contenu et ça ne rivalise pas avec ce que tu décris, mais quoi que tu construises pour le contenu a besoin d’une chose en dehors de lui affirmant que la vérification de contenu elle-même a encore fonctionné.
(Divulgation, puisqu’elle est dans le nom du compte : nous construisons la moitié structurelle. La moitié contenu que tu décris est la plus difficile, et je ne pense pas qu’une version générique en existe.)