Todos los días a las 4:15 de la mañana, sin que nadie prenda un computador, este mensaje llega a Slack. Lo arma una automatización de n8n: doce pasos encadenados que tardan 46 segundos. Esta página los abre uno por uno.
Recorte del mensaje real del 30 de agosto de 2026. El original trae seis segmentos de Google, uno de Bing y el bloque de comentarios completo.
Una automatización es una receta: algo la dispara, ella va a buscar datos a varios lados, hace las cuentas y entrega el resultado. n8n es el tablero donde dibujas esa receta. Cada paso es una caja y las flechas dicen quién le pasa el resultado a quién. No escribes una aplicación: armas la receta conectando bloques en orden.
Cada caja hace una sola cosa y recibe lo que produjo la anterior. Si una falla, la cadena se detiene ahí y sabes exactamente en cuál caja se rompió. Esa es la mitad del valor: el error siempre tiene una dirección.
Lo otro que conviene entender desde el principio: la automatización no sabe nada. No decide, no interpreta, no improvisa, no aprende. Hace exactamente lo mismo todos los días, en el mismo orden, con los mismos umbrales. Toda la inteligencia está en cómo la armaste — y por eso una automatización buena es sobre todo una decisión bien escrita.
Los nombres en gris son los que aparecen en el tablero de n8n. Los milisegundos son los de la corrida real de esta mañana.
Es lo único que arranca todo. Guarda una expresión de cron, 15 4 * * *, que se lee: minuto 15, hora 4, todos los días. La zona horaria está fijada en America/Bogota, así que 4:15 es 4:15 acá y no en el servidor. Nadie la toca: mientras el workflow esté activo, dispara solo.
Unas líneas de código que resuelven qué días hay que pedir: ayer, anteayer y el mismo día de la semana pasada. Se calculan solas a partir de la fecha de hoy, así que nadie tiene que actualizar fechas a mano — ni el 1 de enero, ni el 29 de febrero.
Una llamada a la API de Google Ads por lo que solo la plataforma sabe: cuánto se gastó, cuántos clics hubo y el impression share — qué porcentaje de las búsquedas disponibles alcanzamos a cubrir. Google contesta de inmediato, en menos de un segundo.
La plata — ingresos, órdenes, ROAS — no sale de Google: sale del CDP de Trafilea, vía Redash. Y Redash no contesta al instante: recibe el encargo, lo pone en una fila y se va a calcular. Este paso solo deja el pedido puesto y sigue. Por eso tarda 53 milisegundos y no 15 segundos.
Idéntico al anterior, con otra fecha. Sirve para la comparación “vs. ayer” que aparece en el mensaje final.
El mismo día de la semana anterior. Un lunes se compara contra un lunes, nunca contra un sábado: el tráfico de un ecommerce cambia demasiado entre días de la semana como para comparar a ciegas.
El paso más largo de todos, y el que no hace nada. Le da tiempo a Redash de terminar las tres consultas. Es el 97% de la duración total del workflow.
Vuelve por el resultado del pedido 04. Ahora sí está listo y llega completo: ingresos, órdenes, add-to-carts e initiate-checkouts, campaña por campaña.
Lo mismo para la segunda fecha.
Y la tercera. Con esto la automatización ya tiene todo en la mano: plataforma de un lado, negocio del otro, tres días para comparar.
El único paso que “piensa”, y aun así no piensa: ejecuta reglas escritas de antemano. Clasifica cada campaña en su segmento leyendo el nombre — si dice _br_ es marca, si dice _nb_ es no-marca —, cruza los ingresos del CDP con el gasto de la plataforma, compara cada segmento contra su target de CPA y de ROAS, pinta el semáforo, y redacta las viñetas de comentario. Todo eso en una décima de segundo.
Publica el texto como mensaje directo. Fin del recorrido. La automatización no vuelve a hacer nada hasta las 4:15 del día siguiente.
De los 46 segundos que dura todo, 45 son de espera pura. No es lentitud ni un error de diseño: es cómo funciona la fuente de datos.
Cuando le pides a Redash una consulta pesada, no te devuelve los datos. Te devuelve un “listo, la puse en la fila”. Después se va a recorrer meses de información y deja el resultado guardado. Si preguntaras por él enseguida, no habría nada que recoger.
Entonces la automatización hace lo mismo que harías tú en una fila de banco: deja los tres pedidos puestos, se sienta, y después pasa a recogerlos. Los 45 segundos no son un cálculo fino — las consultas suelen tardar entre 5 y 20 segundos. Son un margen deliberado, porque un reporte que llega diez segundos tarde no le importa a nadie, y uno que llega vacío sí.
Casi toda automatización que toca un sistema externo se topa con esto. Algunos servicios contestan al instante — Google Ads, Slack. Otros te dan un recibo y te hacen volver — Redash, exportaciones grandes, reportes de Bing. Cuando armes una automatización, la primera pregunta a hacerle a cada fuente es: ¿me contestas ya, o me haces volver? La respuesta define si necesitas una caja de espera en el medio.
Un solo paso — la espera — se come 45 de los 46 segundos. Los otros once caben en el filito de la derecha.
Fuente: registro de ejecución 1522129 en n8n. Las últimas cuatro corridas terminaron todas entre 46,4 y 47,0 segundos — una automatización sana es, sobre todo, aburridamente constante.
Esta automatización manda un reporte de PPC, pero su esqueleto no tiene nada de específico. Cambia el contenido de las cajas y tienes cualquier otra: siempre son estos cuatro bloques, siempre en este orden.
| Bloque | Qué responde | Acá es… | Podría ser… |
|---|---|---|---|
| Disparador | ¿Cuándo arranca? | Un reloj: 4:15 AM diario | Un formulario enviado, un archivo nuevo, un mensaje de Slack, un webhook |
| Buscar | ¿De dónde salen los datos? | Google Ads y el CDP | Shopify, una hoja de cálculo, un CRM, una base de datos, otra API |
| Transformar | ¿Qué hay que hacerles? | Clasificar, comparar contra target, redactar | Filtrar, sumar, deduplicar, traducir, pedirle un resumen a un modelo |
| Entregar | ¿Dónde termina? | Un mensaje directo de Slack | Un correo, una fila en una hoja, una página web, una tarea creada |
La caja de espera de la fase 3 no es un bloque aparte: es un detalle de cómo contesta una de las fuentes.
Este mismo reporte ya existía antes, escrito en Python y corriendo en el Mac de Carlos. Funcionaba — hasta que dejaba de funcionar.
Necesitaba tres cosas al tiempo a las 4:15 de la mañana: el Mac prendido, el Mac despierto y la VPN conectada para poder llegar a Redash. Si el computador dormía o la VPN se caía, no había reporte y nadie se enteraba hasta media mañana.
El 11 de agosto fallaron las dos cosas en el mismo minuto. El reporte de ese día llegó a las 7:32, y solo porque un reintento automático lo alcanzó a rescatar.
Corre en el n8n de Trafilea, que ya vive dentro de la red. No necesita VPN, no necesita el Mac, no necesita que nadie esté despierto ni conectado. Sale igual un domingo, un festivo o en mitad de un viaje.
Las últimas cuatro corridas arrancaron todas a las 09:15:00 en punto y terminaron antes de las 09:15:47. Cuatro de cuatro.
El workflow vive en n8n.production.trafilea.app. Vas a ver exactamente las doce cajas de esta página, conectadas por flechas, en una sola fila. Dos cosas que vale la pena hacer al entrar:
Doble clic en cualquier caja abre lo que hace por dentro, y muestra a la izquierda lo que recibió y a la derecha lo que produjo. Es la mejor forma de entender qué está pasando: ver el dato entrar y salir.
La pestaña de ejecuciones guarda cada corrida de los últimos días, con el mismo detalle. Si un día el reporte no llega, ahí está la caja exacta donde se rompió, en rojo. No hay que adivinar.