GreenLight

Dans n8n, une étape peut échouer à l'intérieur d'une exécution qui annonce un succès. Un workflow en production l'a fait pendant trois semaines. Son étape en échec avait l'option « continue on fail », alors l'erreur passait comme une donnée ordinaire, chaque exécution finissait au vert et rien n'était envoyé.

Le seul indice était l'horloge (le temps d'exécution était passé de 1,2 à 10,5 secondes), et aucun tableau de bord ne le montrait.

GreenLight lit une instance n8n par son API et compare chaque workflow à son propre historique, sans seuils à configurer. Il fait quatre vérifications, pour une étape en échec dans une exécution réussie, un workflow beaucoup plus lent que d'habitude, un workflow planifié qui s'est arrêté et un autre qui tourne bien moins souvent qu'avant.

Il refuse de juger sans assez d'historique, car une alerte sûre d'elle et fausse coûte plus de confiance qu'une alerte manquée. La première version devinait quels workflows étaient planifiés d'après la régularité de leurs exécutions ; elle passait tous les tests synthétiques et a échoué sur une vraie instance, où une rafale de tests manuels ressemblait à un planning. Aujourd'hui, elle lit le nœud de déclenchement.

Open source sous licence MIT, en version 1.0.0, avec plus de 200 tests et CodeQL dans la CI. Il fonctionne en ligne de commande et avec un tableau de bord local, en anglais et en espagnol, et une démo publique montre le vrai tableau de bord avec des données inventées. Pour l'instant, il tourne sur une seule vraie instance, la mienne.

Il ne peut comparer que l'historique d'exécutions que l'instance conserve encore, donc une courte durée de rétention le limite. Les workflows qui n'ont jamais tourné sont ignorés. L'inspection détaillée se fait par échantillon, et sur une grosse instance une analyse dure le temps que met l'API à répondre.