¿Te sería útil una herramienta que supervise los flujos de trabajo de n8n autohospedado y te alerte sobre fallos?

Built with n8n
1

Estoy considerando crear una pequeña herramienta que monitoree tus flujos de trabajo de n8n autohospedados y te alerte instantáneamente (Discord/Telegram/email) cuando una ejecución falla o se cuelga — porque healthchecks.io/Cronitor no entienden la semántica de n8n (qué nodo se rompió, qué flujo de trabajo). ¿Te sería útil esto? ¿Cuánto estás pagando actualmente por monitoreo, si es que usas alguno?

2

Hola @Thomas42-maker, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@achamm, @Emmas - ustedes han ayudado con problemas similares antes, ¿pueden echar un vistazo?

Sugerido automáticamente por el bot de comunidad de n8n. Es una prueba piloto - comparte tus comentarios aquí.

3

¡Bienvenido @Thomas42-maker!

Sí, esto sería útil - la mayoría de la gente improvisa el flujo de trabajo del Error Trigger incorporado de n8n con algo más porque solo se activa en fallos duros, no en cuelgues o fallos parciales/silenciosos dentro de un flujo de trabajo.

Hay algunas brechas que me gustaría que una herramienta de propósito específico cubriera:

  • Contexto de fallo por nodo (qué nodo falló, con la carga de error real), no solo “el flujo de trabajo X falló”
  • Detectar ejecuciones de larga duración/atascadas, no solo las que se bloquearon - un flujo de trabajo atascado en “en ejecución” durante una hora a menudo significa que un webhook nunca se resolvió o una API externa se está colgando
  • Distinguir errores esperados (p. ej. un límite de velocidad de Slack en el que ya reintentas) de los reales, para que no recibas alertas sobre ruido

Ahora mismo la mayoría de usuarios autohospedados que he visto conectan el Error Trigger a un nodo de Slack/Telegram manualmente y lo dan por hecho, pero se rompe una vez que tienes 20+ flujos de trabajo porque pierdes la visibilidad por nodo. Si tu herramienta puede leer datos de ejecución directamente (a través de la API o BD) y correlacionar fallos a nivel de nodo con contexto de flujo de trabajo, eso solo ya superaría hacer tu propia solución.

1 me gusta
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 me gusta