Être alerté quand un workflow n8n échoue, et quand il ne tourne plus

Par défaut, n8n ne prévient personne quand un workflow de production échoue. Mettre en place un workflow d'erreur, détecter les pannes silencieuses et recevoir une alerte e-mail ou Telegram.

La réponse courten8n ne prévient personne par défaut quand une exécution de production échoue. Il faut créer un workflow contenant un nœud Error Trigger qui envoie une alerte, puis le sélectionner dans les réglages de chaque workflow (Settings → Error workflow). Pour les flux qui s'arrêtent sans erreur, ajoutez un signal de vie.

Étape 1 : créer le workflow d'erreur

Créez un workflow commençant par le nœud Error Trigger. Il reçoit, à chaque échec, le nom du workflow, le nœud en cause, le message d'erreur et l'URL de l'exécution. Ajoutez ensuite un nœud d'envoi : e-mail, Telegram, Slack ou Microsoft Teams. Ce workflow n'a pas besoin d'être activé pour fonctionner.

Un modèle prêt à importer est disponible dans les modèles n8n gratuits.

Étape 2 : le relier à chaque workflow

Dans chaque workflow de production : Settings → Error workflow → sélectionnez votre workflow d'alerte. C'est l'étape la plus souvent oubliée : sans elle, l'Error Trigger ne reçoit rien.

Étape 3 : conserver les exécutions en erreur

Vérifiez que Save failed production executions est activé, sinon vous ne pourrez pas comprendre la panne après coup.

Étape 4 : détecter les pannes sans erreur

Le workflow d'erreur ne voit que les échecs. Il ne voit pas un flux planifié qui ne se déclenche plus, un webhook qui ne reçoit plus rien ou un filtre qui laisse tout passer. Pour ceux-là :

  • Signal de vie : en fin de flux planifié, un appel HTTP vers Healthchecks.io ou Uptime Kuma. Si l'appel n'arrive pas à l'heure prévue, vous êtes alerté.
  • Contrôle de volume : un flux compare chaque jour le nombre d'exécutions ou d'éléments traités à la normale.
  • Contrôle métier : un flux vérifie qu'à chaque devis entrant correspond bien un contact dans le CRM.
Type de panneDétectée par
Erreur dans un nœudWorkflow d'erreur (Error Trigger)
Flux planifié arrêtéSignal de vie
Webhook qui ne reçoit plus rienContrôle de volume
Données perdues entre deux outilsContrôle métier
Instance n8n arrêtéeSurveillance de disponibilité externe

Et si l'instance elle-même tombe ?

Un workflow d'erreur hébergé sur l'instance en panne ne partira jamais. Ajoutez une surveillance externe de l'URL de votre instance (Uptime Kuma sur un autre serveur, ou un service en ligne).

Questions fréquentes

Le workflow d'erreur doit-il être actif ?

Non. Un workflow qui commence par Error Trigger est appelé par n8n même s'il est inactif.

Peut-on avoir un seul workflow d'erreur pour tous les flux ?

Oui, c'est la pratique recommandée : un workflow d'erreur commun, sélectionné dans les réglages de chaque flux.

L'Error Trigger se déclenche-t-il pendant les tests manuels ?

Non, uniquement pour les exécutions de production (déclenchées automatiquement).

À lire aussi

Trente minutes pour savoir ce qui est automatisable chez vous.

Vous décrivez le processus, je vous dis si je peux aider, à quel prix et en combien de temps. Sinon, je vous oriente vers la bonne personne.

Décrire mon besoin