Una automatización que falla necesita algo más que un registro: alguien debe enterarse y saber qué revisar. Las alertas de errores en n8n permiten preparar esa respuesta mediante un flujo específico de gestión de fallos.
El objetivo de esta guía es configurar y comprobar el aviso. La recuperación del proceso, los reintentos y la prevención de duplicados requieren decisiones adicionales. Aquí proponemos una configuración de referencia y una lista de pruebas para adaptarla a tu instalación.
Qué es un Error Workflow
La documentación de n8n explica que un flujo de errores comienza con Error Trigger y se vincula desde la configuración del flujo que quieres supervisar. Cuando una ejecución vinculada falla, recibe información del error y puede ejecutar acciones de aviso. Un mismo flujo de errores puede atender varios procesos.
Como recomendación organizativa, empieza por un proceso concreto y un único destinatario de prueba. Una vez validado, podrás ampliar el alcance con una lista clara de responsables.
Configura el aviso paso a paso
- Crea un flujo nuevo y añade
Error Triggercomo primer nodo. - Conecta el canal de aviso que tengas configurado y autorizado, por ejemplo correo.
- Prepara un mensaje breve con el nombre del proceso y una indicación para investigar.
- Guarda el flujo con un nombre reconocible.
- Abre los ajustes del flujo principal y selecciónalo en
Error workflow. - Guarda los cambios y prepara una prueba controlada.
Según la documentación del nodo, el flujo de errores no necesita publicarse. Los nombres y la disposición de los controles pueden variar según la versión; utiliza la documentación de tu instalación si la interfaz es diferente.
Qué información debe contener el mensaje
El nodo puede proporcionar datos del flujo, mensaje de error, último nodo ejecutado y enlace a la ejecución. No supongas que todos los campos estarán disponibles: el identificador y el enlace dependen de que la ejecución se haya guardado, y los fallos del disparador pueden aportar una estructura diferente.
Recomiendo comenzar con una plantilla mínima y revisar su contenido antes de habilitarla para procesos reales:
- Proceso: nombre comprensible para la persona responsable.
- Impacto posible: qué tarea puede haber quedado pendiente.
- Referencia: enlace a la ejecución si existe.
- Siguiente acción: dónde revisar y quién debe hacerlo.
Evita incluir el cuerpo completo de un formulario, credenciales o documentos en una notificación. Como criterio de diseño, conserva el detalle necesario en el sistema con acceso apropiado y utiliza el aviso para dirigir la investigación.
Prueba una ejecución automática
La documentación de Error Trigger advierte de que no se prueba ejecutando manualmente el flujo principal: el nodo actúa ante errores de ejecuciones automáticas. n8n también documenta Stop And Error para provocar un fallo bajo una condición elegida.
Como propuesta de ensayo, utiliza una copia del flujo con datos ficticios y un disparador automático de prueba. Añade un fallo deliberado que no afecte a clientes ni active acciones reales. Comprueba el registro de la ejecución, la ejecución del flujo de errores y la recepción del mensaje.
No des la prueba por superada solo porque aparezca un nodo verde. Anota hora, proceso, mensaje recibido y persona que lo verificó. Después retira la condición de fallo y confirma el funcionamiento normal.
Diseña qué hacer después de recibir la alerta
Un aviso necesita una instrucción operativa. Recomiendo definir, para cada proceso, quién revisa la incidencia y qué comprobación debe hacer antes de relanzarlo.
Ejemplo hipotético: una integración guarda una solicitud en WordPress y después falla al comunicarla a otra herramienta. Antes de repetir todo el flujo, comprueba qué pasos ya se completaron. La guía de reintentos e idempotencia desarrolla cómo abordar el riesgo de duplicados.
Si la conexión incluye WordPress, documenta también los permisos y el alcance de la integración. Puedes continuar con n8n y WordPress: automatización segura y la introducción a webhooks y APIs.
Comprueba el caso en que no llega ninguna alerta
Como diseño de supervisión, plantea otra pregunta: ¿cómo sabrás que el proceso dejó de ejecutarse? Un fallo registrado y una ausencia de actividad requieren pruebas diferentes. Recomiendo documentar por separado la frecuencia esperada y la revisión de actividad, especialmente en tareas importantes.
Prepara también una prueba del propio canal de avisos. Decide cómo detectarás un problema de entrega y evita depender únicamente del mensaje que ese mismo canal tendría que enviar para avisar de su avería.
Lista de aceptación
- El flujo principal tiene asignado el flujo de errores correcto.
- Una prueba automática controlada produce el aviso esperado.
- El mensaje sigue siendo útil si falta el enlace de ejecución.
- La notificación no expone datos innecesarios.
- Existe un responsable y un procedimiento para investigar.
- Se comprueba por separado la actividad esperada del proceso.
¿Necesitas automatizaciones con seguimiento?
En automatización e integraciones puedo ayudarte a definir avisos, pruebas y recuperación según el proceso.
Fuentes oficiales
Documentación consultada el 26 de octubre de 2026. Los ejemplos son hipotéticos y las pruebas propuestas deben realizarse con datos ficticios y acciones externas controladas.
