Necesito empezar a monitorear mejor los flujos de trabajo.
¿Cómo lo están haciendo ustedes?
@patriciaLee la respuesta nativa que la mayoría de la gente se pierde es el Error Workflow, configura uno globalmente en Settings y se ejecuta en cualquier ejecución fallida para que puedas enviar el error a slack/email/donde sea sin necesidad de hacer polling. para navegar/auditar está la vista Executions con filtros de estado. y si estás auto-alojado, configura N8N_METRICS=true para exponer un endpoint /metrics de prometheus que puedas scrapear en grafana para dashboards y alertas. error workflow + metrics cubre la mayoría de configuraciones en producción.
Hay dos categorías que evalúo. La primera categoría es la salud de la ejecución. Quiero saber si la ejecución comenzó, finalizó o encontró un error. La otra categoría es el resultado empresarial. Tengo que determinar si la ejecución hizo lo que se suponía que debía hacer. Esta categoría es más difícil de evaluar. Por ejemplo, si una ejecución causó que un filtro omitiera todos los registros, entonces la ejecución sería exitosa pero completamente inútil.
Si un flujo de trabajo es lo suficientemente importante, registraré más detalles, incluido el número de registros procesados, el estado final del flujo de trabajo, la razón por la que falló el flujo de trabajo, el propietario del flujo de trabajo y el próximo paso propuesto.
Además de los errores, monitoreo algunos otros síntomas. Por ejemplo, si los flujos de trabajo no se han completado exitosamente, si el número de registros procesados cae a 0, o si hay un número creciente de intentos de reintento, emitiré una alerta. Siempre me esfuerzo por hacer que las alertas sean accionables.
@patriciaLee achamm cubrió lo fundamental (Error Workflow + vista de Executions + Prometheus/Grafana) — esa es la base correcta. Dos cosas que agregaría para cubrir lo que esos no capturan:
-
Hacer que el Error Workflow sea realmente accionable. Una alerta desnuda de “un workflow falló” no es suficiente. En tu Error Workflow global, envía un mensaje que incluya el nombre del workflow, la URL de ejecución, el nodo que falló y el mensaje de error — eso convierte una búsqueda de 20 minutos en un salto de un clic a la ejecución rota. También configura EXECUTIONS_DATA_SAVE_ON_ERROR=all (y elimina ejecuciones exitosas con la configuración data-prune) para que mantengas ejecuciones fallidas para depuración sin saturar la BD.
-
Vigilar las SILENT failures — el punto ciego real. Error Workflow + métricas solo se disparan cuando un workflow se ejecuta y falla. No capturan un workflow que silenciosamente deja de ejecutarse — un trigger que muere, un webhook que se desregistra, un cron que se detiene calladamente. Ese es el fallo que realmente duele, porque te enteras días después por el cliente. La solución es un dead-man’s switch: un Schedule trigger que haga ping a un servicio de heartbeat (Healthchecks, Better Stack, o Uptime Kuma autohospedado) cada pocos minutos. Si el ping deja de llegar, te alerta — así capturas “dejó de ejecutarse en absoluto,” no solo “se ejecutó y tuvo error.”
Si estás autohospedado, también pondría un monitor de uptime básico en la instancia/contenedor de n8n mismo, para que sepas si el todo está caído versus solo un workflow.
La configuración en capas que ejecutaría: Error Workflow con contexto rico para fallos en tiempo de ejecución → Prometheus/Grafana para salud agregada → un heartbeat/dead-man’s switch para paradas silenciosas → un monitor de uptime en la instancia. La mayoría configura los primeros dos; el heartbeat es el que casi todos olvidan hasta que te muerde.
Buen punto de @ShawnWilliams al distinguir integridad de ejecución vs. resultado empresarial. Un ejemplo de la segunda categoría que quizá ayude: he construido un flujo de trabajo diario que no monitorea errores, sino oportunidades de contenido, busca en posts de foros y evalúa mediante LLM si son relevantes para mí, luego envía un resumen por correo.
El punto es: “monitoreo” no tiene que significar solo errores. Puedes usar el mismo mecanismo de flujo de errores para también reconocer triggers positivos, ya sean nuevos leads, contenidos, u preguntas abiertas que puedas responder. La base técnica (configuración de achamms) se mantiene igual, solo cambia la condición que dispara la alerta de “error ocurrido” a “evento interesante detectado”.
@patriciaLee y otros cubrieron las piezas fundamentales (Error Workflow, vista de Executions, Prometheus/Grafana y la distinción entre health de ejecución vs. resultados de negocio). Yo añadiría una capa más que me ha causado problemas en producción: fallos silenciosos.
Error Workflows y métricas solo ayudan cuando algo realmente se ejecuta y lanza un error. No detectan un trigger que deja de dispararse, una suscripción a webhook que expira silenciosamente (los watches de Gmail son un ejemplo clásico), o un cron job que nunca se ejecuta. Nada se ejecuta, así que nada se observa. En mi experiencia, esos suelen ser los fallos más dolorosos porque los descubres a través de un cliente en lugar de desde el monitoreo.
El enfoque que he adoptado es un dead-man’s switch: un workflow programado hace ping a un servicio de heartbeat (Healthchecks.io, Better Stack, o Uptime Kuma autohospedado). Si el heartbeat deja de llegar, esa es la alerta. Complementa Error Workflows detectando “dejó de ejecutarse completamente”, no solo “se ejecutó y falló”.
También me gusta el punto de Shawn sobre resultados de negocio. Para workflows importantes, hago seguimiento de cosas como registros procesados, conteos de reintentos, volúmenes mínimos esperados y propiedad. Un workflow que procesa exitosamente cero registros puede estar técnicamente saludable pero operacionalmente inútil, así que esas métricas también merecen alertas.
El modelo en capas que me ha funcionado bien es:
- Error Workflow → contexto enriquecido (workflow, nodo, URL de ejecución, detalles del error)
- Prometheus/Grafana → métricas agregadas y tendencias
- Métricas de negocio → registros procesados, reintentos, resultados esperados
- Heartbeat/dead-man’s switch → fallos silenciosos
- Monitoreo de uptime → salud de instancia/contenedor
La mayoría de las personas implementan las primeras dos capas. Las capas de heartbeat y resultados de negocio son las que tienden a salvarte de sorpresas desagradables después.
La división de Shawn es la que usaría: salud de ejecución vs resultado comercial.
Para flujos de clientes agregaría un pequeño recibo de ejecución a la alerta: ventana esperada, registros tocados, cuenta/credencial utilizada, acción posterior intentada, id final de registro/mensaje, y quién es responsable del siguiente paso. La ejecución en verde es menos útil que la prueba de qué cambió.
Este hilo ya tiene bien cubierta la división importante entre la salud de la ejecución frente a si el resultado realmente ocurrió, más la idea del latido del corazón para la ejecución que nunca se activa, así que solo agregaré el único fallo que sigue escapándose de todo eso. Incluso con una verificación de recuento de registros y un interruptor de seguridad en su lugar, el caso que atrapa a la gente es la ejecución que se completa, procesa su número habitual de filas, no lanza nada y sigue siendo incorrecta, porque una credencial expiró silenciosamente o una fuente quedó obsoleta y la API devolvió una respuesta válida pero vacía o de marcador de posición. El recuento se ve normal, el estado es verde, nada genera errores, así que ninguna de las capas anteriores lo señala.
La razón por la que un Disparador de Error estándar es ciego a esto es que no hubo error. El token no falló ruidosamente, devolvió un 200 limpio sin nada útil dentro, y el flujo de trabajo felizmente lo mapeó hacia adelante. Una alerta de recuento de registros también lo pierde, porque el recuento puede ser normal mientras el contenido está obsoleto o en blanco.
Lo que lo atrapa sin mucho esfuerzo es verificar el contenido, no solo la presencia. Después de cualquier llamada sensible a la autenticación, afirma en un campo que solo aparece cuando la llamada funcionó genuinamente, en lugar de solo verificar que la respuesta no esté vacía, y agrega una verificación de actualización: ¿el registro más nuevo es realmente reciente o me estoy mirando los datos de ayer que me devolvieron? Para el ángulo de credencial específicamente, ayuda tratar un resultado inesperadamente vacío de una fuente normalmente ocupada como una condición de fallo en lugar de un éxito silencioso.
La mentalidad que une todo el hilo: una ejecución verde con un recuento de filas normal aún no es prueba de que los datos sean reales, solo que algo volvió. La verificación que vale la pena agregar es si el resultado es fresco y correcto, no solo presente. ¿Qué hacen ustedes sobre el caso obsoleto pero verde, o aún no les ha mordido?
Este hilo cubre bien las capas principales: flujo de errores con contexto, Prometheus/Grafana, latido del corazón para fallos silenciosos, y el caso verde pero antiguo que alguien planteó. Una brecha que añadiría, especialmente si no estás ejecutando n8n de forma aislada:
Todo lo mencionado hasta ahora es nativo de n8n. Flujo de errores, N8N_METRICS, la vista de ejecuciones. Es la decisión correcta si n8n es tu única superficie de automatización. Pero muchos equipos no son puramente n8n. Tienen escenarios de Make, un par de zaps de Zapier, un trabajo cron, quizá un script o dos, todos haciendo trabajo real en producción. Cada uno tiene su propio panel, así que “¿está todo saludable?” significa revisar tres o cuatro lugares diferentes, y el patrón de latido del corazón que la gente describió aquí tiene que reconstruirse por separado para cada herramienta.
El patrón que me ha funcionado: tratar “¿se ejecutó, tuvo éxito, falló?” como un evento simple que dispares desde donde viva la automatización. Una llamada HTTP desde los caminos de éxito y error de n8n, lo mismo desde un webhook de Make o un webhook de Zapier o un try/except en un script, todos llegando a un solo lugar que no le importa qué herramienta lo envió. La misma idea de latido del corazón que arriba, solo que no atada a una plataforma.
Aclaración porque debería decirlo directamente: construí una herramienta para exactamente esto (FlowPulse) después de encontrarme con este mismo problema de “cuatro paneles, ninguna vista única” yo mismo. No intento meter un discurso de ventas en medio de un buen hilo, solo lo señalo por si la parte multiplataforma es útil para alguien. Feliz de hablar también sobre la versión DIY si ese es más tu estilo.