Alertes avec n8n : supervision et notifications que personne ne rate

Un import de données s'interrompt à deux heures du matin, l'interface avec le système de gestion des marchandises ne renvoie plus que des messages d'erreur, et personne ne s'en aperçoit avant le lendemain matin. Le dommage vient rarement de l'erreur elle-même, mais des heures pendant lesquelles personne ne la remarque. C'est précisément là qu'interviennent les alertes avec n8n : détecter les dysfonctionnements et les signaler sur des canaux de plus en plus urgents, jusqu'à ce que quelqu'un réagisse.

Une alerte avec n8n se compose de trois parties : un déclencheur qui repère l'erreur (Error Trigger, Schedule Trigger ou Webhook), une logique de vérification qui décide s'il faut alerter et avec quelle urgence, et des nœuds de notification pour l'e-mail, Microsoft Teams, le SMS ou l'appel téléphonique. Si personne ne réagit dans un délai défini, le workflow passe au niveau d'escalade suivant.

Pourquoi les alertes sont le cas d'usage n8n sous-estimé

La plupart des entreprises utilisent n8n pour la synchronisation de données et l'automatisation des processus, alors que la supervision est l'un des cas d'usage au bénéfice le plus rapide. Les services d'alerte spécialisés facturent par utilisateur et par mois et sont souvent surdimensionnés pour une petite équipe. Avec n8n, vous utilisez un outil que de nombreuses entreprises exploitent déjà de toute façon, et vous gardez la logique d'alerte en interne : qui est notifié, quand et à propos de quoi est décrit dans un workflow que vous pouvez lire et modifier vous-même.

Le schéma s'applique à presque tout système doté d'une interface : boutique en ligne, système de gestion des marchandises, serveur de sauvegarde, formulaires de site web. Vous trouverez d'autres exemples concrets dans nos cas d'usage.

Les briques : déclencheur, logique de vérification, canaux

Chaque alerte dans n8n commence par l'un de trois types de déclencheurs, qui déterminent comment un problème est repéré en premier lieu :

• Error Trigger : démarre un workflow d'erreur dédié dès qu'un autre workflow n8n échoue. Il est renseigné dans les paramètres du workflow surveillé en tant qu'Error Workflow et reçoit les détails de l'exécution ayant échoué.
• Schedule Trigger : s'exécute selon un intervalle ou une expression cron, par exemple toutes les cinq minutes, et vérifie activement si un système répond, si une sauvegarde existe ou si un seuil est dépassé.
• Webhook : reçoit des messages de l'extérieur, par exemple d'un outil de supervision de serveur ou d'une application capable d'envoyer elle-même des alertes.

Après le déclencheur vient la logique de vérification, le plus souvent un nœud IF ou Switch : l'erreur est-elle critique ou seulement un avertissement ? Est-ce les heures de travail ou le week-end ? Ce n'est qu'ensuite que viennent les canaux. n8n intègre des nœuds prêts à l'emploi pour l'e-mail, Microsoft Teams et Slack ; le SMS et les appels téléphoniques passent par des services comme Twilio ou sipgate via une API. Une alerte sérieuse doit passer par un canal qui réveille aussi la nuit.

La façon dont nous mettons en place et exploitons de tels workflows pour les entreprises est présentée sur notre page de prestation dédiée à l'automatisation n8n.

Une chaîne d'escalade, étape par étape

Une chaîne d'escalade typique comporte trois niveaux et ne nécessite qu'un seul workflow dans n8n. Niveau un : l'Error Trigger se déclenche, le workflow formate le message d'erreur et le publie dans un canal Teams, accompagné d'un lien d'accusé de réception. Ce lien pointe vers un webhook qui marque le message comme pris en charge. Niveau deux : un nœud Wait met le workflow en pause, par exemple 15 minutes. Si aucun accusé n'a été donné d'ici là, un e-mail part vers le responsable d'équipe, là encore avec un lien d'accusé de réception. Niveau trois : après 15 minutes supplémentaires sans réaction, le workflow déclenche un SMS ou un appel téléphonique vers l'astreinte.

L'accusé de réception est essentiel. Sans lui, soit tout remonte jusqu'à l'appel, soit la chaîne s'interrompt après le premier message et personne ne sait si quelqu'un s'en occupe. Qui a pris en charge et quand est consigné dans le journal d'exécution grâce au webhook d'accusé de réception.

Auto-surveillance : qui alerte quand n8n lui-même est à l'arrêt

Une supervision qui ne se surveille pas elle-même a un angle mort : si le serveur n8n est à l'arrêt, aucun Error Trigger ne se déclenche non plus. La solution est un heartbeat, aussi appelé dead man's switch. Un petit workflow avec Schedule Trigger se signale toutes les quelques minutes auprès d'un service de contrôle externe comme Healthchecks.io ou un Uptime Kuma auto-hébergé. Si le signe de vie s'arrête, le service externe donne l'alerte, quoi qu'il soit arrivé à n8n. Ainsi, les deux systèmes se surveillent mutuellement.

Erreurs courantes dans les alertes avec n8n

Les erreurs les plus fréquentes dans les alertes avec n8n ne sont pas techniques mais conceptuelles. Nous rencontrons ces cinq-là sans cesse dans la pratique :

• Tout alerte : si la moindre broutille déclenche un message, tout le monde finit par se lasser et la seule alerte importante passe inaperçue. D'abord prioriser, ensuite notifier.
• Error Workflow non attribué : le workflow d'erreur existe, mais il n'est pas renseigné comme Error Workflow dans les paramètres des workflows surveillés. Dans ce cas, rien ne se passe en cas d'erreur.
• Testé uniquement manuellement : selon la documentation n8n, l'Error Trigger ne s'exécute que lors d'exécutions automatiques, pas lors de tests manuels. Celui qui ne teste que manuellement croit à tort que ses alertes fonctionnent.
• Un seul canal : si les alertes passent exclusivement par Teams, elles tombent avec lui lorsque Microsoft 365 est perturbé. Au moins un canal devrait être indépendant, par exemple le SMS.
• Pas d'auto-surveillance : sans heartbeat, personne ne remarque quand le gardien lui-même tombe en panne.

À cela s'ajoute un point organisationnel : une chaîne d'escalade a besoin de personnes qui décrochent au bout. Avant de la construire, clarifiez qui assure l'astreinte. La technique est la partie la plus simple.

Questions fréquentes

Qu'est-ce que l'Error Trigger dans n8n ?

L'Error Trigger est un nœud qui démarre un workflow d'erreur dédié dès qu'un workflow qui lui est associé échoue. Il reçoit les détails de l'exécution ayant échoué, comme le nom du workflow et le message d'erreur, et il est attribué dans les paramètres du workflow surveillé sous Error Workflow. Avec le nœud Stop And Error, on peut en plus déclencher ses propres erreurs.

n8n peut-il appeler automatiquement en cas d'erreur ?

Oui, via des services de téléphonie dotés d'une API comme Twilio ou sipgate. Le workflow n8n appelle l'interface du fournisseur et déclenche ainsi un SMS ou un appel vocal avec un message. Pour des alertes occasionnelles, cela ne représente que quelques centimes de frais de fournisseur.

Comment surveille-t-on n8n lui-même ?

Avec un heartbeat : un workflow avec Schedule Trigger se signale à intervalles courts auprès d'un service de contrôle externe comme Healthchecks.io ou Uptime Kuma. Si le signalement s'arrête, le service externe alerte. Ainsi, une panne du serveur n8n est repérée alors même que n8n ne peut plus rien envoyer.

n8n remplace-t-il les services d'alerte spécialisés comme PagerDuty ?

Pour de petites équipes avec un parc de systèmes maîtrisable, généralement oui : niveaux d'escalade, accusé de réception et plusieurs canaux se laissent entièrement modéliser dans n8n. Celui qui doit gérer des plans d'astreinte complexes avec rotations et des dizaines de participants sera mieux servi par un service spécialisé.

Cela fonctionne-t-il aussi avec un n8n auto-hébergé ?

Oui, toutes les briques décrites sont également disponibles dans la variante auto-hébergée. Pour les entreprises qui tiennent à la souveraineté allemande des données, c'est la voie habituelle : les messages d'erreur ne quittent alors votre propre environnement que pour l'envoi de la notification.

Les alertes ne sont pas un projet qui prend des semaines. Un premier workflow d'erreur avec deux niveaux d'escalade est en place en quelques heures, et le heartbeat qui l'accompagne le jour même. Lors de la prochaine panne nocturne, vous ne l'apprendrez pas du client à huit heures du matin, mais vous réagirez vous-même à deux heures de la nuit.