La automatización no se monta una vez y se olvida: hay que vigilarla

La mentira más extendida de todo esto es "lo montas una vez y funciona para siempre".

No. Lo montas una vez y funciona hasta que algo cambia fuera. Y fuera cambia constantemente: las APIs se actualizan, las contraseñas caducan, los servicios cambian de plan, alguien renombra una columna. Tu flujo no se rompe por tu culpa. Se rompe porque el mundo se movió y él no.

Lo peor no es que se rompa. Es que se rompa en silencio.

¿Cuánto mantenimiento pide una automatización?

Menos de lo que se tarda en hacer la tarea a mano, casi siempre. Pero no cero, que es lo que la gente presupone.

Por experiencia, un flujo estable pide atención unas pocas veces al año. Una revisión cuando el servicio actualiza algo, una renovación de credenciales, un ajuste cuando cambias tu propio proceso. Ninguna de esas visitas es larga. El problema es que llegan sin avisar y siempre en mal momento.

Y hay una parte que se acumula: el coste de mantenimiento no crece con cada flujo, crece con cada conexión entre servicios. Un flujo que toca cuatro herramientas tiene cuatro sitios por donde romperse. Diez flujos sencillos dan menos guerra que tres flujos que tocan todo.

Por eso la regla de si compensa automatizar no puede ser solo de tiempo ahorrado. Hay que meter el mantenimiento en la cuenta o la cuenta sale mal, y sale mal siempre en la misma dirección: a favor de automatizar cosas que no lo merecían.

Las cinco formas en que se te muere un flujo

He tenido las cinco. Van por orden de frecuencia real.

Uno: las credenciales caducan. Un token que se renovaba solo deja de renovarse. Cambias la contraseña de una cuenta y se te olvida que había un flujo usándola. Activas la verificación en dos pasos en un servicio y el acceso automático se queda fuera. Esta es la número uno con diferencia y es la más tonta.

Dos: la API cambia. El servicio actualiza su versión, un campo cambia de nombre, un endpoint se retira. Suelen avisar por correo, a una dirección que no lees, con seis meses de antelación. El día que llega, tu flujo devuelve un error que no habías visto nunca.

Tres: cambia el formato de lo que entra. Alguien añade una columna a la hoja, o empieza a escribir las fechas de otra manera, o mete un acento donde no había. Tu flujo sigue ejecutándose feliz y produce basura. Este es el más peligroso, porque no da error.

Cuatro: te comes un límite. El plan gratuito tenía mil ejecuciones al mes y tu flujo creció. Deja de ejecutarse el día veinte y vuelve solo el uno del mes siguiente. Durante diez días has tenido medio negocio parado y ni te has enterado.

Cinco: cambias tú. Reorganizas carpetas, renombras un proyecto, cambias de herramienta para otra cosa. Y un flujo que llevaba un año funcionando apunta a un sitio que ya no existe.

El fallo silencioso es el que te arruina el mes

Un flujo que falla y avisa es una molestia de diez minutos.

Un flujo que falla y no avisa es lo que te hace descubrir en enero que llevas desde octubre sin registrar los avisos de un formulario. Y ahí ya no hay arreglo: la información no se recupera.

A mí me pasó con una automatización que sí me costó dinero, y lo conté entero en la automatización que me costó dinero. El resumen: no fue un error espectacular, fue un flujo haciendo silenciosamente lo que le pedí durante semanas.

Por eso la primera regla de mantenimiento no es revisar más. Es que el sistema te avise.

Cómo monto la vigilancia sin volverme loco

Cuatro capas, de menos a más esfuerzo. Con las dos primeras ya vas bastante servido.

Uno: notificación de error activada. Tanto n8n como Make tienen aviso por correo cuando una ejecución falla. Es una casilla y casi nadie la marca. Márcala hoy en todos tus flujos y ya te has quitado la mitad del problema.

Dos: latido, no solo errores. Los avisos de error no detectan un flujo que ha dejado de ejecutarse. Si el disparador no salta, no hay error que reportar: hay silencio. Para eso hace falta lo contrario, algo que compruebe que la cosa sigue viva. Yo tengo un agente que revisa que lo importante siga corriendo y me escribe si algo lleva demasiado tiempo callado. Lo monté siguiendo lo que cuento en un agente que me avisa cuando algo falla.

Tres: validación en la entrada. Antes de procesar nada, comprobar que los datos tienen la pinta que deben tener. Si el campo viene vacío o la fecha no es una fecha, parar y avisar en vez de seguir adelante. Esto es lo que te salva del fallo silencioso del punto tres de la lista anterior.

Cuatro: revisión periódica en el calendario. Una vez al trimestre, veinte minutos mirando la lista de flujos activos y preguntándome si cada uno sigue teniendo sentido. Siempre hay dos que sobran y uno que lleva meses muerto.

Documentar es parte del mantenimiento

Esta es la que más pereza da y la que más tiempo ahorra.

Cuando un flujo se rompe, casi nunca se rompe la semana después de montarlo. Se rompe ocho meses más tarde, cuando ya no te acuerdas de por qué pusiste ese paso raro en medio ni qué cuenta usaste para conectar.

Yo escribo cuatro líneas por flujo: qué hace, qué lo dispara, qué cuentas usa y qué pasa si falla. Cuatro líneas. Se tarda dos minutos y convierte una tarde de arqueología en diez minutos de arreglo.

Y hay un motivo extra ahora: si tienes eso escrito, se lo puedes pasar a una IA cuando algo falle y te ayuda a localizar el problema en vez de tener que reconstruir el contexto tú desde cero.

En qué caso me equivocaría

Me equivocaría si estás montando tres flujos sencillos para tu uso personal.

Si tu automatización manda un recordatorio a tu propio móvil, no necesitas capas de vigilancia. El día que deje de llegar el recordatorio te vas a enterar, porque el que lo espera eres tú. Ese es un sistema que se monitoriza solo.

Todo lo que cuento aquí empieza a hacer falta cuando el flujo toca a otra persona. Un cliente, un suscriptor, un compañero. Ahí el silencio ya no lo detectas tú, lo detecta el afectado. Y se entera él antes que tú, que es la peor forma posible de enterarse.

El mapa completo de cómo montar esto sin que se te vaya de las manos está en la guía de automatización y agentes con IA.

Lo que yo asumo desde el principio

Que todo flujo que monto lo voy a tener que tocar.

Con esa premisa, las decisiones cambian. Lo monto más sencillo, porque lo sencillo se arregla rápido. Lo documento, porque sé que voy a volver. Le pongo aviso, porque sé que va a fallar. Y no lo hago crítico si puedo evitarlo, porque sé que un día no estará.

La automatización no es un electrodoméstico. Es más bien una planta. Nace, funciona sola casi siempre, y si no la miras nunca, un día está seca y llevaba meses.

Algunos enlaces de este artículo son de afiliado: si contratas la herramienta, me llevo una comisión sin que a ti te cueste más.

Si quieres montar tu sistema de automatizaciones de forma que se sostenga solo y te avise cuando algo se rompe, es una de las piezas centrales de Yo SA.

Ver Yo SA