21 de agosto de 2026 · breachreel_adm

Cómo gestionar errores y ejecuciones fallidas en n8n

Nodo rojo fallido analizado y desviado hacia una ruta de recuperación azul

Un workflow no está terminado cuando funciona una vez. También debe explicar qué ocurrió cuando falla, conservar la información necesaria para diagnosticarlo y avisar a la persona adecuada.

Resumen rápido

  • Distingue errores temporales de datos inválidos.
  • Guarda suficiente contexto sin conservar secretos innecesarios.
  • Utiliza Error Trigger para centralizar alertas.
  • Añade reintentos solo cuando la operación sea segura.
  • Comprueba que las propias alertas funcionan.

Por qué fallan los workflows

Los fallos habituales incluyen credenciales caducadas, límites de API, respuestas inesperadas, tiempos de espera, falta de memoria y datos que no cumplen el formato previsto.

Clasificar el tipo de fallo ayuda a decidir la respuesta. Un error temporal puede admitir un reintento; un email inválido requiere corregir el dato; una credencial revocada necesita intervención.

Revisar una ejecución fallida

Desde la sección Executions puedes abrir una ejecución y localizar el primer nodo que falló. Revisa la entrada, la salida, el código de estado y el mensaje del proveedor.

No te limites al último mensaje. El problema puede haberse originado varios nodos antes, cuando un campo quedó vacío o cambió de tipo.

  • Identifica el primer nodo con error.
  • Comprueba el dato exacto que recibió.
  • Compara con una ejecución correcta.
  • Reproduce el fallo con información no sensible.
  • Documenta la causa antes de cambiar el workflow.

Crear un workflow de errores

n8n permite crear un workflow que comienza con Error Trigger. Después puedes asociarlo desde la configuración de otros workflows para recibir los detalles cuando una ejecución falla.

El workflow de errores puede enviar una notificación por correo o mensajería, crear una incidencia o registrar el evento en una tabla. La alerta debe incluir el nombre del workflow, la ejecución y un resumen, pero no secretos completos.

Utilizar Stop And Error

No todos los fallos son errores técnicos. Si una condición de negocio invalida el proceso, el nodo Stop And Error permite detener la ejecución de forma explícita.

Esto resulta útil cuando falta un identificador obligatorio, un importe está fuera del rango permitido o la respuesta de una API no contiene la confirmación esperada.

Reintentos e idempotencia

Reintentar puede resolver límites temporales o interrupciones, pero también puede duplicar acciones. Antes de reintentar un pago, un correo o una creación de registro, comprueba si la operación es idempotente.

Utiliza identificadores únicos y consulta el estado anterior cuando sea posible. Define un número máximo de intentos y aumenta gradualmente el intervalo para no empeorar una limitación de frecuencia.

Controlar los datos de ejecución

Guardar todas las ejecuciones para siempre aumenta la base de datos y puede conservar información personal innecesaria. n8n permite configurar qué datos de ejecución se almacenan.

Una política razonable conserva errores el tiempo suficiente para investigar y reduce o elimina ejecuciones correctas cuando no aportan valor operativo. La decisión depende del proyecto y de sus obligaciones.

Probar el sistema de alertas

Provoca un fallo controlado en un workflow de prueba y confirma que la alerta llega con información útil. Después comprueba qué ocurre si el canal de aviso también está caído.

Un sistema de monitorización que nunca se prueba puede generar una falsa sensación de seguridad.

Fuentes oficiales


Continúa aprendiendo

Consulta la guía introductoria de BreachReel o descubre la formación estructurada para avanzar desde los fundamentos hasta automatizaciones completas.