Un workflow de n8n que corre una vez por día a las 3 AM y falla silenciosamente es peor que no tener automatización. Lo descubrís al mes siguiente cuando alguien pregunta dónde están los reportes. Para entonces, el equipo perdió confianza en el sistema, hay datos faltantes, y el costo de recuperación es mucho mayor que cualquier ahorro que el workflow generaba.
Este post junta los patrones que usamos para que nuestros workflows fallen ruidosamente cuando algo se rompe, se autorrecuperen cuando pueden, y nos notifiquen cuando no. Ninguno es especialmente sofisticado. Lo que importa es que estén, no que sean elegantes.
Los 3 tipos de error que tenés que distinguir
Antes de diseñar la respuesta, hay que diagnosticar. Los errores en workflows caen en tres categorías y cada una merece un tratamiento distinto.
Errores transitorios. Un rate limit de la API, un timeout de red, un servicio caído por 30 segundos. Estos desaparecen solos si esperás un poco y reintentás. El patrón correcto es retry con backoff exponencial.
Errores de datos. Un input mal formado, un campo ausente, un valor fuera de rango. Reintentar no sirve; el mismo input va a fallar igual. Estos errores requieren detección, log detallado y notificación para intervención humana.
Errores de sistema. El workflow mismo tiene un bug, una credencial venció, una API cambió su contrato. Son los más críticos porque suelen afectar todas las ejecuciones hasta que alguien los repara. Detección + alarma inmediata.
La trampa común es tratarlos todos igual. Retry automático de un error de datos genera docenas de intentos que siempre fallan y crece el problema. Notificación de cada error transitorio spamea al equipo hasta que nadie mira las alertas. Distinguir los tres es el primer paso.
Error Trigger + error workflow: lo mínimo indispensable
n8n tiene un nodo especial, el Error Trigger, que se dispara automáticamente cuando cualquier workflow del sistema falla y tiene asociado un "error workflow". Es la base de cualquier estrategia de error handling y mucha gente no lo sabe o no lo usa.
El patrón mínimo:
- Crear un workflow llamado, por ejemplo, "Error Handler".
- El primer nodo es un Error Trigger.
- Los siguientes nodos hacen: loguear a algún destino persistente (una tabla en Postgres, una fila en Sheets, Sentry, lo que sea), decidir si vale la pena notificar, y si sí mandar una alerta (Slack, email, Telegram).
- En cada workflow de producción, settings → "Error Workflow" → seleccionar este error handler.
Esto te da una red de seguridad universal: cualquier workflow que falle y no tenga manejo local va a disparar el error workflow. No es perfecto porque es reactivo (el workflow original ya falló), pero es muchísimo mejor que no tener nada.
Retry con backoff exponencial: cuándo sí y cuándo no
n8n tiene retry configurable a nivel de nodo. Podés decirle a un HTTP Request que reintente hasta 5 veces con 2 segundos entre intentos. El default que recomendamos no es ese; es un backoff exponencial: 2, 4, 8, 16 segundos.
La razón: si el problema es un rate limit, esperar 2 segundos no alcanza. Si el problema es un servicio caído, los primeros reintentos son optimistas y los últimos dan tiempo real de recuperación. Backoff exponencial hace los intentos baratos y los últimos útiles.
Pero retry solo debería aplicarse a errores claramente transitorios. Detalles clave:
No reintentes errores 4xx. Un 400 Bad Request, 401 Unauthorized o 422 Validation Error no se arreglan solos. Los 5xx sí; los 4xx no. Muchos nodos de n8n reintentan todo por default y eso hace que un error de datos se convierta en una tormenta de requests idénticos.
No reintentes operaciones no idempotentes sin idempotency key. Si tu nodo crea un registro y el primer intento falló después de crear pero antes de recibir confirmación, un retry puede crear un duplicado. Usá idempotency keys (la mayoría de las APIs buenas las soportan) o protegé con un check previo.
Limitá los intentos. 3 a 5 es el rango razonable para retries automáticos. Más que eso indica que el problema no es transitorio y estás sumando latencia sin resolver nada.
Idempotencia: el concepto que más te va a ahorrar
Un workflow es idempotente si correrlo dos veces con el mismo input produce el mismo resultado que correrlo una vez. Los workflows idempotentes son dramáticamente más fáciles de debuggear y recuperar de errores.
Ejemplos prácticos:
- Mal: un workflow que lee pedidos nuevos y los inserta en Sheets. Si algo falla a mitad, los primeros se insertan, los últimos no. Si rerunás, los primeros se duplican.
- Bien: el mismo workflow, pero con un check previo ("¿este pedido ya está en Sheets?") o usando un campo ID único como clave primaria con upsert.
Diseñar para idempotencia desde el inicio cambia el carácter del error handling. En lugar de "si falla, tengo que limpiar y retomar exactamente desde donde quedó", pasa a ser "si falla, rerunás el workflow y sale bien". Esto es la diferencia entre un workflow reparable y uno que siempre requiere intervención manual cuidadosa.
Dead letter queue: para jobs que no se arreglan solos
Los errores de datos son distintos a los transitorios. Si un input viene malformado, reintentar no lo va a arreglar. Pero tampoco querés que el workflow entero se detenga: querés procesar los 99 items que vinieron bien y poner el item roto en una cola de revisión.
El patrón del dead letter queue (DLQ):
- Dentro del loop principal del workflow, cada item se procesa dentro de un "Try/Catch" (en n8n se implementa con el nodo Error Trigger local o con el modo "Continue on Fail").
- Si un item falla, se escribe en un destino separado (una tabla "errors", una Sheets "to_review", una cola en Redis) con: el input original, el error, el timestamp, y opcionalmente un trace.
- El workflow sigue con los demás items.
- Un workflow separado monitorea el DLQ y notifica si hay items nuevos. Humanos los revisan, corrigen y los reinyectan.
Este patrón convierte "el workflow falló" en "el workflow terminó, con 3 items en revisión". Operacionalmente es muchísimo mejor.
Alertas: no todas las fallas merecen despertarte
El instinto es alertar a Slack en cada error. Tres días después, nadie mira el canal. Es el mismo problema de los alarmas de seguridad en edificios: si suenan todo el tiempo, son ruido.
Nuestra regla:
Alertar inmediatamente (Slack, email, PagerDuty) cuando: un workflow crítico para el negocio falla completamente, o el DLQ de un workflow importante acumula más de N items, o una credencial está a punto de expirar.
Loguear sin alertar cuando: un item individual falla y va al DLQ, un retry tuvo éxito después de 1-2 intentos, un workflow no crítico falla (los revisás en el dashboard semanal).
Dashboard diario/semanal para: métricas agregadas, tendencias, errores acumulados, workflows que no corrieron cuando debían.
La distinción "crítico vs no crítico" la definís por workflow al momento de poner en producción. Un cierre mensual es crítico. Un sync nocturno de métricas no lo es. Los dos tienen error handling, pero las alarmas son muy distintas.
El patrón del "health check" workflow
Un patrón que nos ha salvado muchas veces: un workflow separado que cada N horas verifica que los workflows críticos están funcionando. No mira ejecuciones individuales: mira heartbeats.
Cada workflow crítico, al terminar exitosamente, escribe un timestamp en una tabla "last_success" con su nombre. El health check workflow corre cada hora, compara los timestamps esperados con los actuales, y alerta si alguno está "muerto" (más de X horas sin heartbeat).
Esto detecta un tipo de falla que el error handling local no captura: el workflow que simplemente nunca corrió. Puede ser por un crash del VPS, un bug en el scheduler, una config mal cambiada. Si confiás solo en errores de ejecución, nunca te enterás. Con heartbeats, lo detectás en horas.
Idempotencia de notificaciones
Una trampa con la que nos cruzamos más de una vez: el error handler mismo falla. El workflow crashea, el error handler intenta mandar una notificación a Slack, Slack está caído o la credencial venció, y nadie se entera nunca.
La regla: el path de notificación tiene que ser más simple y más robusto que el workflow que monitorea. Si usás Slack, tené un canal secundario (email, Telegram) como fallback. Si el error handler también loguea a Postgres, el dashboard lo recoge aunque la notificación falle.
Un checklist para workflows de producción
Antes de darle "activate" a un workflow nuevo en producción, nuestra checklist:
- ¿Tiene configurado un error workflow a nivel global?
- ¿Los nodos de HTTP tienen retry config? ¿Con backoff exponencial?
- ¿El retry está desactivado para 4xx? ¿Activado solo para 5xx y timeouts?
- ¿Las operaciones son idempotentes o tienen idempotency key?
- ¿Hay un DLQ para errores de datos en loops?
- ¿Está claro qué constituye "falla crítica" vs "falla procesable"?
- ¿Hay heartbeat al final para detectar que nunca corrió?
- ¿La notificación crítica va a un destino que vamos a mirar?
- ¿Probamos qué pasa si la API upstream tira 500? ¿Y 429? ¿Y 403?
- ¿Documentamos cómo intervenir manualmente si algo grande se rompe?
Ninguno de estos puntos es innovador. Lo innovador es hacerlos todos. Los workflows en producción sin este tipo de disciplina son deuda técnica que eventualmente va a cobrar.
El punto
Automatización sin error handling es automatización hasta el primer incidente serio. Todo workflow que va a producción debe asumir que va a fallar de alguna manera y diseñar para que esa falla sea: visible, contenida, y recuperable. Las herramientas en n8n para hacer esto existen; lo que falta casi siempre es la intención de usarlas. La diferencia entre un proyecto de automatización exitoso y uno que se abandona seis meses después es exactamente esa intención.