Cuando las automatizaciones fallan

La primera automatización que construí funcionó limpia durante tres semanas y yo estaba orgullosísimo. Entonces, un martes, la API del otro lado se cayó un rato, el workflow se rompió a mitad, y un cliente recibió dos correos de confirmación en vez de uno. Nadie me había dicho que algo había salido mal. Me enteré cuando el cliente se quejó.

Ese es el momento en el que la mayoría se da cuenta: construir una automatización es una mitad. Construirla de forma que no rompa nada cuando algo falla es la otra. Y de eso va justamente esto.

En las lecciones anteriores aprendiste cómo funcionan Zapier y n8n y qué es un webhook. Ahora miramos qué pasa cuando ese webhook precisamente no responde. Porque en algún momento no lo hará.

Por qué fallan las automatizaciones

Una automatización es una cadena. Disparador, luego paso uno, luego paso dos, y así. Cada paso habla casi siempre con algún sistema ajeno, una API, una base de datos, un servidor de correo. Y los sistemas ajenos son justo eso: ajenos. No tienes control sobre ellos.

Los motivos más habituales de que un paso se caiga son banales. El otro lado está saturado en ese momento y responde con un error. La conexión tarda demasiado y se va a timeout. Un registro tiene un campo que no esperabas, vacío o con formato equivocado. O se ha alcanzado un límite, demasiadas peticiones en muy poco tiempo.

Lo puñetero es que estos fallos suelen ser pasajeros. Un segundo después la misma llamada habría funcionado. Precisamente por eso la primera línea de defensa no es ningún montaje complicado, sino sencillamente volver a intentarlo.

Retry, simplemente intentarlo otra vez

Las dos herramientas grandes lo traen de serie, y deberías activarlo casi siempre.

En n8n el ajuste se llama Retry On Fail y está directamente en cada nodo, en los ajustes del nodo. Indicas dos valores: Max Tries, o sea cuántos intentos como máximo, y Wait Between Tries (ms), o sea cuánto se espera entre ellos. Un buen valor de partida para la mayoría de casos es Max Tries 3 y Wait Between Tries 1000, o sea tres intentos con un segundo de pausa. Conviene saberlo: la interfaz limita estos valores. Max Tries llega como mucho a 5, y el tiempo de espera como mucho a 5000 milisegundos. Si necesitas pausas más largas o más intentos, tendrás que apañarte con tu propia lógica de bucle, pero eso ya no es tema de principiantes.

En Zapier funciona al revés. En vez de configurar reintentos por adelantado, trabajas con Replay. Una ejecución fallida de un Zap aterriza en el historial con estado errored, y desde ahí la puedes volver a reproducir. En el plan gratuito eso va a mano y solo para ejecuciones con estado de error. Quien lo quiera automático necesita Autoreplay, un ajuste que reproduce por su cuenta las ejecuciones fallidas. Eso sí, solo está a partir del plan Professional. Un detalle con el que tropieza mucha gente: si cambias mucho el Zap después del fallo, las ejecuciones fallidas antiguas ya no se pueden repetir limpiamente.

El retry resuelve sorprendentemente muchos problemas. Pero no todos. Y aquí es donde se pone interesante.

El problema de ejecutar dos veces

Imagínate que tu workflow hace dos cosas. Primero crear un pedido en la base de datos, después mandar un correo de confirmación. La base de datos va bien, el correo va bien, pero después el workflow se cae por alguna tontería. El retry vuelve a lanzar toda la ejecución. Resultado: segundo pedido, segundo correo. Justo mi problema del martes de antes.

El término técnico para esto es idempotencia. Una operación es idempotente cuando da igual que se ejecute una vez o cinco, el resultado es el mismo. Poner un interruptor de la luz en encendido es idempotente, darle cinco veces a encendido no cambia nada. Crear un pedido nuevo no lo es, cada pasada genera otro.

En la práctica lo resuelves con una clave única. Cada pedido recibe un ID, por ejemplo el número de pedido. Antes de que tu workflow cree un pedido nuevo, comprueba: ¿existe ya una entrada con ese ID? Si la hay, saltar. Así el peligroso "volver a crear" se convierte en un inofensivo "ya está, seguimos".

No hace falta que hagas esto en todas partes. Pero allí donde tu workflow genera o envía algo que una persona va a ver o a pagar, merece la pena pensarlo. Mejor comprobar una vez de más que mandarle a un cliente dos facturas.

Dónde meter los casos que simplemente no pasan

A veces no ayuda ningún retry. El registro está roto, falta un campo obligatorio, la lógica no encaja. Si dejas que un caso así se cuele sin más, desaparece en silencio y tú no te enteras nunca.

La idea que conviene recordar aquí se llama dead letter, viene a ser el buzón del correo no entregable. En vez de tirar un registro roto o bloquear todo el workflow, lo apartas. A una hoja de cálculo propia, a una tabla, a un canal aparte. Ahí se van juntando los casos que necesitan mano humana, y el resto sigue corriendo.

En n8n usas para eso la opción Continue (using error output) en el nodo de petición HTTP. En vez de abortar el workflow, el nodo abre una segunda salida para el caso de error, y a esa salida le enganchas tu lógica de apartar. En Zapier montas el mismo efecto con paths y con la decisión sobre cómo maneja los errores un Zap.

El asunto es siempre el mismo. Un único registro roto no puede parar toda la máquina, y tampoco puede desaparecer sin dejar rastro.

Tienes que enterarte cuando algo arde

Esa es la lección que me enseñó el cliente que se quejó. La mejor gestión de errores no sirve de nada si no te enteras de que ha pasado algo.

Alertar significa sencillamente: cuando un workflow falla, te sale un aviso. Un correo, un mensaje de Telegram, una entrada en un canal de Slack. n8n tiene para esto un mecanismo propio, que puedes registrar como workflow de error, de forma que ante un corte salte automáticamente una notificación. En Zapier puedes hacer que te avisen por correo cuando un Zap pasa a estado de error.

Lo importante es solo que el mensaje te diga en concreto qué ha pasado. "Workflow pedido fallido" vale la mitad que "workflow pedido fallido, paso envío de correo, número de pedido 4815, error timeout". Con la segunda variante sabes de inmediato dónde tienes que mirar.

Y un consejo honesto de la práctica: no hagas tus alertas demasiado ruidosas. Si cada pequeño retry que se cura solo te manda un aviso, a los tres días dejas de mirarlos. Avisa de los casos que de verdad necesitan mano, no de cada hipo.

Cómo abordarlo ahora

No tienes que construirlo todo de golpe. Empieza pequeño. Repasa tu automatización existente y activa el retry en cada paso que hable con un sistema ajeno. Tres intentos, un segundo de pausa. Eso ya atrapa la mayor parte de los fallos pasajeros.

Después piensa qué paso genera algo que no puede estar duplicado, y mete ahí una comprobación de idempotencia. Y para terminar monta una única notificación que te avise cuando un workflow haya fallado del todo. Para empezar no hace falta más.

En el capstone de este nivel construyes una automatización completa. Llévate esto contigo. Una automatización que solo funciona cuando hace buen tiempo es un prototipo. Una que tampoco rompe nada cuando llueve es una herramienta.

Fuentes

• Retry On Fail de n8n, Max Tries y Wait Between Tries, además de Continue using error output en el nodo HTTP Request: https://n8nautomationtutorial.com/n8n-http-request-node-retry-on-fail-error-handling-retry-logic
• Comunidad de n8n sobre los límites de la interfaz Max Tries 5 y Wait Between Tries 5000 ms: https://community.n8n.io/t/node-max-tries-wait-values-limits-too-low/46284
• Replay de ejecuciones de Zap en Zapier: https://help.zapier.com/hc/en-us/articles/8496241726989-Replay-Zap-runs
• Autoreplay de Zapier y comportamiento ante errores (a partir del plan Professional): https://help.zapier.com/hc/en-us/articles/14167175792909-Decide-how-your-Zap-handles-errors-with-advanced-settings