Un outil qui surveille les workflows n8n auto-hébergés et alerte en cas de défaillance vous serait-il utile ?

Built with n8n
1

Je réfléchis à la création d’un petit outil qui surveille vos workflows n8n auto-hébergés et vous alerte instantanément (Discord/Telegram/e-mail) lorsqu’une exécution échoue ou se bloque — parce que healthchecks.io/Cronitor ne comprennent pas la sémantique de n8n (quel nœud a échoué, quel workflow). Cela vous serait-il utile ? Que payez-vous actuellement pour la surveillance, le cas échéant ?

2

Salut @Thomas42-maker, en attendant une réponse, voici quelques ressources qui pourraient t’aider :

Ressources suggérées

Automatiquement associées à ta question.

Documentation :

Forum :

@achamm, @Emmas - vous avez déjà aidé sur des problèmes similaires, pouvez-vous y jeter un œil ?

Automatiquement suggéré par le bot communautaire de n8n. C’est un projet pilote - veuillez partager vos commentaires ici.

3

Bienvenue @Thomas42-maker !

Oui, ce serait utile - la plupart des gens assemblent le workflow Error Trigger natif de n8n avec autre chose parce qu’il ne se déclenche que sur les défaillances matérielles, pas sur les blocages ou les défaillances partielles/silencieuses à l’intérieur d’un workflow.

Quelques lacunes que j’aimerais qu’un outil dédié couvre :

  • Contexte de défaillance par nœud (quel nœud a échoué, avec la charge utile d’erreur réelle), pas juste « le workflow X a échoué »
  • Détecter les exécutions longues/bloquées, pas seulement les exécutions arrêtées - un workflow bloqué à l’état « running » pendant une heure signifie souvent qu’un webhook n’a jamais été résolu ou qu’une API externe est en train de bloquer
  • Distinguer les erreurs attendues (par exemple une limite de débit Slack sur laquelle vous avez déjà un retry) des erreurs réelles, pour ne pas être alerté sur du bruit

En ce moment, la plupart des utilisateurs auto-hébergés que j’ai vus connectent manuellement l’Error Trigger à un nœud Slack/Telegram et s’arrêtent là, mais ça ne tient pas une fois que vous avez 20+ workflows puisque vous perdez la visibilité par nœud. Si votre outil peut lire directement les données d’exécution (via l’API ou la BD) et corréler les défaillances au niveau du nœud avec le contexte du workflow, ça suffirait déjà à battre une solution maison.

1 « J'aime »
4

Thanks, this is exactly the kind of detail I needed. Quick follow-up: would you (or people you’ve seen) actually pay for this as a subscription, or is it something you’d only use if it were free/open-source? And roughly how many workflows does someone need before this pain becomes serious enough to pay for?

5

From what I’ve seen, most self-hosted users won’t pay until they hit 15-20+ production workflows, that’s usually when manual monitoring stops scaling and a missed failure actually costs money or trust with a client. Below that, people lean on free options (Error Trigger + Slack, or Uptime Kuma push) since the pain isn’t big enough yet. On pricing, a low-cost subscription (10-20 USD/month) beats one-time or open-source for this kind of tool, because ongoing alerting/monitoring feels like infrastructure people expect to pay recurring for, similar to Uptime Kuma Cloud or Better Stack. I’d focus your free tier on catching people right before that 15-20 workflow threshold, then convert them once they feel the pain.

1 « J'aime »