Surveiller ses workflows n8n : pourquoi un statut « succès » ne prouve rien

Une automatisation qui plante bruyamment n'est pas le problème. Le problème, c'est celle qui s'arrête sans rien dire : les demandes de vos clients cessent d'arriver dans votre CRM, les plannings ne partent plus, et vous l'apprenez trois semaines plus tard, par un client. Voici comment nous surveillons nos propres workflows n8n, et ce que nous avons appris à nos dépens.

Les pannes qui ne font pas de bruit

Sur plusieurs années d'automatisations en production, les pannes qui nous ont coûté le plus n'avaient rien de spectaculaire. Elles se ressemblaient toutes : rien ne s'affichait en rouge, et pourtant plus rien ne se passait.

• Un workflow désactivé. Quelqu'un l'éteint pour un essai, ou n8n le désactive après une mise à jour. Il ne tourne plus, donc il n'échoue plus, donc personne n'est prévenu.
• Une connexion expirée. Une application Google laissée en mode test voit son autorisation expirer au bout de sept jours. Un jeton est révoqué par un changement de mot de passe. Le workflow tourne, l'appel échoue.
• Une erreur avalée. Une étape réglée pour continuer en cas d'erreur laisse passer une réponse vide. L'exécution se termine en vert. Le résultat n'existe pas.
• Une API qui change. Un logiciel renomme un champ. Le workflow lit une valeur vide et écrit une fiche incomplète, tous les jours, sans broncher.
• Un déclencheur qui ne déclenche plus. Le formulaire de votre site est cassé : le webhook n'est jamais appelé. n8n n'a rien à vous reprocher, il n'a rien reçu.

Pourquoi le workflow d'erreur de n8n ne suffit pas

n8n propose un mécanisme natif : un workflow d'erreur, déclenché quand une exécution échoue. C'est utile, et nous l'utilisons. Mais il ne couvre qu'une seule des pannes ci-dessus. Il ne voit pas un workflow désactivé, puisque rien ne s'exécute. Il ne voit pas une erreur avalée, puisque l'exécution réussit. Il ne voit pas un déclencheur muet. Et il ne voit rien du tout si le serveur n8n lui-même est arrêté.

Surveiller sérieusement, c'est regarder à trois endroits différents.

Niveau 1 : l'état

Le premier niveau répond à une question simple : ce qui doit tourner tourne-t-il ? Toutes les cinq minutes, un workflow de surveillance interroge l'API de n8n. Il liste les workflows marqués comme devant rester actifs (chez nous, par une étiquette surveille) et vérifie qu'ils le sont. Il liste les exécutions en erreur depuis le dernier passage. Il appelle les adresses publiques qui comptent, site et formulaires, et vérifie qu'elles répondent.

L'étiquette est importante. Sans elle, la surveillance alerte sur chaque brouillon et chaque essai, et une alerte qui sonne pour rien est une alerte qu'on finit par ignorer.

Niveau 2 : le résultat

Le deuxième niveau répond à une question plus exigeante : ce que le workflow devait produire existe-t-il ? Un statut « succès » dit que les étapes se sont enchaînées, pas que la fiche a été créée, ni que le message est arrivé.

Notre règle : chaque chaîne se termine par une étape qui relit le résultat réel. La fiche CRM est relue après sa création. L'envoi Telegram n'est considéré comme fait que si Telegram confirme la réception. Si la relecture échoue, l'exécution échoue, et le niveau 1 la voit.

Niveau 3 : l'absence

Le troisième niveau est le plus souvent oublié : ce qui devait arriver est-il arrivé ? Un formulaire de contact qui ne reçoit aucune demande pendant cinq jours alors qu'il en reçoit trois par jour d'habitude, ce n'est probablement pas un hasard. Un rapport du matin qui n'est pas parti, c'est une panne, même si aucune exécution n'a échoué.

D'où un principe que nous appliquons partout : un message attendu part toujours, même quand il n'y a rien à dire. Notre récapitulatif quotidien envoie « rien à signaler » plutôt que de se taire. Ainsi le silence garde un sens : il veut dire panne.

Une alerte que l'on lit

Une surveillance ne vaut que par l'attention qu'on lui porte. Trois règles évitent qu'elle devienne du bruit :

1. Une alerte, puis un rappel espacé. Une alerte à la détection, un rappel toutes les heures tant que le problème dure, pas toutes les cinq minutes.
2. Un message de retour. Quand tout est rétabli, un message le dit. Sans lui, personne ne sait si quelqu'un s'en est occupé.
3. Le bon canal. Pas un e-mail noyé parmi cent autres, mais une messagerie que l'on regarde vraiment, chez nous Telegram, avec le nom du workflow et la cause en clair.

Et qui surveille la surveillance ?

Si le serveur n8n tombe, le workflow de surveillance tombe avec lui. Il faut donc un regard extérieur, même minimal : un service tiers qui appelle votre n8n de l'extérieur et prévient si l'instance ne répond plus. C'est le seul point que l'on ne peut pas confier à n8n lui-même.

La sauvegarde fait partie de la surveillance

Une base n8n finit un jour par se corrompre, une mise à jour se passe mal, quelqu'un supprime un workflow par erreur. Chaque nuit, notre surveillance exporte tous les workflows par l'API et les envoie dans un endroit séparé du serveur. La base complète, avec ses connexions et son historique, se sauvegarde en plus côté serveur. Restaurer un workflow prend alors cinq minutes au lieu d'une journée de reconstruction de mémoire.

La liste de contrôle

• Chaque workflow qui doit rester actif porte une étiquette, et rien d'autre ne la porte
• Une vérification toutes les cinq minutes : workflows désactivés, exécutions en erreur, adresses publiques
• Chaque chaîne se termine par la relecture du résultat réel
• Les messages attendus partent même quand il n'y a rien à dire
• Alerte, rappel horaire, message de retour, sur un canal que l'on lit
• Un contrôle externe de l'instance n8n elle-même
• Une sauvegarde nocturne des workflows, hors du serveur

Questions fréquentes

Comment être alerté quand un workflow n8n s'arrête ?

Avec un workflow de surveillance qui interroge l'API de n8n toutes les cinq minutes : il vérifie que les workflows marqués comme devant rester actifs le sont, liste les exécutions en erreur et prévient sur une messagerie lue, par exemple Telegram. Le workflow d'erreur natif de n8n ne suffit pas, car il ne voit pas un workflow désactivé.

Le workflow d'erreur de n8n suffit-il pour surveiller ses automatisations ?

Non. Il ne se déclenche que lorsqu'une exécution échoue. Il ne détecte ni un workflow désactivé, ni une erreur ignorée par une étape réglée pour continuer, ni un déclencheur qui ne reçoit plus rien, ni un serveur n8n arrêté.

Pourquoi une exécution n8n peut-elle réussir sans avoir rien produit ?

Parce qu'un statut « succès » indique seulement que les étapes se sont enchaînées. Une étape réglée pour continuer en cas d'erreur, ou une API qui renvoie une réponse vide, laisse l'exécution finir en vert. Il faut terminer chaque chaîne par une étape qui relit le résultat réel.

Comment sauvegarder ses workflows n8n ?

En exportant chaque nuit tous les workflows par l'API de n8n vers un stockage séparé du serveur. La base complète, qui contient aussi les connexions et l'historique, se sauvegarde en plus au niveau du serveur.