La automatización que me costó dinero por no probarla

Hay un momento muy concreto en el que una automatización deja de ser útil y pasa a ser un problema: cuando la activas, cierras la pestaña y te vas a hacer otra cosa.

Eso hice yo. Monté un escenario, lo dejé corriendo y me fui a grabar. Cuando volví, un par de horas después, tenía cientos de ejecuciones en el historial y el contador de operaciones del mes casi a cero.

No fue una catástrofe. Fue una tontería que se podía haber evitado con dos minutos de prueba. Y precisamente por eso me molestó tanto.

¿Qué había antes y qué quise automatizar?

El flujo era ridículamente simple sobre el papel. Cada vez que entraba un formulario nuevo, quería que se creara una fila en una base de datos, que se mandara un correo de aviso y que, si la persona marcaba cierta casilla, se le añadiera una etiqueta.

Lo hacía a mano. Me llevaba treinta segundos por registro y entraban unos cuantos al día. O sea, nada dramático, pero es exactamente el tipo de tarea que se convierte en peaje mental: pequeña, repetitiva y siempre pendiente.

Lo monté en Make porque para flujos visuales de este tipo se tarda menos en dibujarlo que en explicarlo. Cinco módulos. Quince minutos.

Y ahí empezó el problema.

El bucle que no vi venir

El error fue de manual, y por eso lo cuento.

Uno de los pasos escribía en la misma base de datos que estaba vigilando el disparador. O sea: entra un registro, el escenario lo procesa, el escenario escribe una modificación en ese registro, y esa modificación despierta otra vez al disparador. Que vuelve a procesar. Que vuelve a escribir.

Una serpiente comiéndose la cola, pero cobrando por mordisco.

En automatizaciones visuales esto pasa más de lo que parece, porque el disparador de "fila creada o modificada" viene marcado por defecto en un montón de conectores. Tú lees "modificada" y piensas "bien, así también capturo ediciones". Y lo que estás haciendo es abrir la puerta al bucle.

Cuando volví al ordenador, el historial estaba lleno de ejecuciones idénticas separadas por segundos. Yo tenía el plan intermedio, con un paquete de operaciones mensual bastante holgado. Me lo fundí en una tarde. El coste real fue tener que ampliar el plan a mitad de mes para que el resto de escenarios no se pararan, más una hora larga de limpiar registros duplicados a mano.

Lo peor no fue el dinero. Fue que durante esas dos horas los correos de aviso también se dispararon. Recibí decenas del mismo formulario. Y si en vez de a mí, eso le llega a un cliente, la conversación es otra.

¿Qué puede salir mal en una automatización?

Después de aquello me senté a hacer la lista de lo que de verdad rompe estas cosas. No es una lista larga. Son tres cosas, y las tres son evitables.

Uno: el bucle. Un paso que modifica lo mismo que dispara el flujo. Es el error caro, el que se te come el plan. Se detecta mirando una sola pregunta: ¿este escenario escribe en el sitio que está vigilando? Si la respuesta es sí, hay que meter un filtro que corte la segunda vuelta. Por ejemplo, una columna de estado que solo deje pasar los registros marcados como "sin procesar".

Dos: el dato que no viene. Tú montas el flujo con un registro de prueba bonito, con todos los campos rellenos. Y luego llega alguien que deja el teléfono en blanco, o que escribe el nombre con un emoji, o que manda el formulario dos veces seguidas. El módulo revienta, el escenario se detiene y tú no te enteras hasta tres días después. La parte incómoda es que el fallo silencioso es peor que el bucle: el bucle grita, el fallo silencioso te deja creyendo que todo funciona.

Tres: el volumen que no calculaste. Una automatización que se ejecuta cuarenta veces al día no cuesta nada. La misma automatización enganchada a algo que se dispara cada minuto es otra factura. Antes de activar, multiplicar: ejecuciones estimadas por número de módulos, por treinta días. Si el número te asusta, el flujo no está listo.

Esto conecta con algo que ya he contado en otro sitio: la automatización sin mantenimiento no existe. Montarla es el 20% del trabajo. El otro 80% es que siga funcionando cuando cambie el mundo alrededor.

¿Cómo pruebo un escenario sin arriesgar nada?

Lo que hago ahora, siempre, antes de dejar nada activo:

Ejecuto el flujo una sola vez a mano, con un registro de prueba, y miro el resultado paso por paso. No solo el verde de "ha ido bien". Miro qué dato exacto ha entrado en cada módulo y qué ha salido.

Luego lo ejecuto una segunda vez con el mismo registro. Esto es la prueba clave del bucle: si al ejecutarlo dos veces se crean dos filas donde debería haber una, o el escenario se vuelve a disparar solo, ahí lo tienes.

Después meto un dato feo a propósito. Un campo vacío, un texto larguísimo, un correo mal escrito. Quiero ver el error en mi pantalla, no en producción.

Y solo entonces lo activo, pero con un límite. En Make se puede fijar el número máximo de ciclos y la frecuencia de comprobación. Si el escenario solo necesita mirar cada quince minutos, no lo dejes en uno. Ahí se va la mitad del consumo de mucha gente sin que nadie lo note.

Cuando el flujo es crítico, además le pongo un aviso de fallo. Un paso final que, si algo peta, me manda un mensaje. Prefiero un aviso de más que enterarme por un cliente.

Lo que cambié después: n8n en mi propio servidor

Parte de esto lo acabé moviendo a n8n montado en un servidor mío. No por moda, por una razón muy concreta: cuando pagas por operación, cada error te cuesta dinero. Cuando pagas por servidor, un bucle te cuesta un susto y un poco de CPU.

Eso no arregla el error, ojo. El bucle sigue siendo un bucle. Pero cambia el precio de equivocarte mientras aprendes, y cuando estás montando cosas nuevas cada semana, ese precio importa.

A cambio, tienes que mantener el servidor tú: actualizaciones, copias de seguridad, el día que algo se cae. Si te da pereza eso, quédate en la herramienta de pago y aprende a mirar el contador. Las dos rutas son válidas, y las he explicado con más detalle en la guía de automatización y agentes con IA.

Lo que no es válido es lo que hice yo: activar y marcharse.

¿Y si el problema es que no había que automatizar eso?

Esta es la pregunta que más me ha ahorrado desde entonces.

Aquella tarea que quise automatizar me llevaba treinta segundos y entraban pocos registros al día. Estamos hablando de unos minutos a la semana. Yo invertí quince minutos en montarlo, luego una hora larga en limpiar el desastre, más el dinero del plan ampliado.

Para recuperar esa inversión en tiempo real necesitaba meses. Y la tarea, encima, iba a cambiar de forma en cuestión de semanas porque estaba rehaciendo el formulario.

Automaticé una tarea que estaba a punto de dejar de existir. Ese es el error que no aparece en ningún tutorial, porque los tutoriales dan por hecho que el flujo que estás montando merece la pena. A veces no. Hay tareas que sale más a cuenta no automatizar, y reconocerlo a tiempo es una habilidad, no una rendición.

Lo que haría distinto

Tres cosas, en este orden.

Probaría el escenario dos veces seguidas antes de activarlo. Solo con eso, aquel bucle no habría existido.

Miraría el disparador con lupa y quitaría "modificado" salvo que lo necesite de verdad. Es la casilla que más dinero se lleva sin que nadie la mire.

Y me preguntaría, antes de abrir la herramienta, cuánto tiempo me ahorra esto al mes de verdad. Si la respuesta se cuenta en minutos y la tarea va a cambiar pronto, la dejo a mano y me voy a automatizar otra cosa.

Automatizar bien no va de montar muchos flujos. Va de montar pocos, probados, y que aguanten cuando tú no estás mirando.

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 no tienes claro por dónde empezar a meter IA y automatización en tu día a día, tengo un test corto que te dice en qué punto estás y qué es lo siguiente que te conviene tocar.

Hacer el test