Hay dos mundos en la automatización. En uno, un formulario dispara un email y todo acaba en dos segundos. En el otro, un proceso nocturno recorre decenas de miles de registros de un ERP, los cruza contra un sistema logístico y genera documentos. El primero cabe en cualquier herramienta. El segundo es donde la mayoría se rompe. Este artículo trata del segundo: qué significa realmente que un proceso "tarde mucho", por qué los límites de tiempo existen, y cómo diseñar automatizaciones de alto volumen que no se corten a la mitad.
Distingue lento de desbocado
Parece lo mismo desde fuera, pero son problemas opuestos y se arreglan al revés:
- Lento: pocos pasos que tardan mucho (una consulta pesada, una API que responde despacio)
- Desbocado: muchísimos pasos en poco tiempo (un bucle que no termina nunca)
- Un proceso lento es legítimo y hay que dejarlo respirar
- Un proceso desbocado hay que cortarlo cuanto antes
💡 Consejo: si tu proceso ejecuta pocos nodos durante mucho rato, es lento, no está roto. Ponerle un límite de tiempo corto solo lo rompe de verdad.
Ajusta el límite de tiempo a la realidad
El tiempo máximo por ejecución existe para que un flujo mal construido no corra para siempre. Pero un valor bajo estorba a los procesos legítimos:
- Mide cuánto tarda de verdad tu proceso en un día de volumen alto, no en uno tranquilo
- Deja margen: el pico de fin de mes no es el martes cualquiera
- En Floogos el límite se sube o se quita por completo
- El freno contra bucles es el tope de pasos, no el reloj — quitar el tiempo no te deja desprotegido
💡 Consejo: mide el peor caso real antes de fijar cualquier límite. Un número elegido a ojo siempre acaba cortando la ejecución equivocada.
Trocea el volumen en lotes
La mejor forma de que un proceso largo no se corte es que deje de ser un proceso largo:
- Procesa por lotes (por fecha, por sucursal, por rango de IDs) en vez de todo de una vez
- Cada lote es una ejecución corta e independiente
- Si uno falla, reintentas solo ese, no las ocho horas enteras
- Ganas visibilidad: ves el avance en vez de esperar a ciegas
💡 Consejo: trocear no solo evita cortes, también reduce la memoria que consume cada ejecución. Dos problemas con una sola decisión.
Ataca el nodo lento, no el proceso entero
Cuando un solo paso se lleva la mayor parte del tiempo, el problema está ahí y no en el flujo:
- Una consulta sin índice puede tardar minutos donde debería tardar segundos
- Traer todas las columnas cuando necesitas tres multiplica el tiempo de transferencia
- Filtra en origen: es mejor que la base devuelva 500 filas que filtrar 50.000 después
- Pon timeouts en el propio nodo, no solo en la ejecución completa
💡 Consejo: antes de subir ningún límite, mira qué nodo se lleva el tiempo. Muchas veces una consulta bien indexada convierte un proceso de horas en uno de minutos.
Entérate cuando algo se corta
Un proceso nocturno que falla en silencio es peor que uno que no existe, porque crees que funcionó:
- Configura un flujo de aviso que se dispare ante cualquier fallo
- Incluye el motivo y el último paso ejecutado en la notificación
- Un corte por tiempo y uno por bucle piden acciones distintas: distínguelos
- Revisa el historial de ejecuciones, no solo el resultado final
💡 Consejo: la señal más valiosa no es "falló", es "falló aquí y por esto". Sin eso, el diagnóstico se convierte en adivinanza.
Checklist para procesos de alto volumen
Preguntas frecuentes
¿Cuánto puede durar una automatización en Floogos?
Por defecto hasta una hora, y el límite se puede subir o quitar por completo. Para procesos nocturnos de alto volumen es habitual ampliarlo o dejarlo sin tope.
¿Es peligroso quitar el límite de tiempo?
No, porque el tiempo no es la defensa principal contra bucles. Un bucle infinito ejecuta miles de pasos en segundos y choca contra el tope de pasos mucho antes de agotar ningún reloj. Un proceso lento pero correcto ejecuta pocos pasos durante mucho rato y nunca se acerca a ese tope.
¿Por qué mi proceso se cortó a los 63 minutos si el límite era de 60?
Porque el corte nunca parte un paso por la mitad. Si el límite vence mientras una consulta está en curso, el motor espera a que termine y corta justo después. Es deliberado: cortar en medio dejaría transacciones abiertas o ficheros a medio escribir.
¿Conviene trocear siempre los procesos largos?
Casi siempre sí. Trocear en lotes reduce el riesgo de corte, baja el consumo de memoria, te permite reintentar solo la parte que falló y te da visibilidad del avance. El coste es un poco más de diseño inicial.
Los procesos que mueven volumen de verdad son los que más valor generan y los que peor tratan la mayoría de herramientas, porque asumen que todo termina en segundos. Diseñar para el volumen es distinguir lento de roto, trocear cuando se puede, atacar el paso lento en vez del proceso entero, y enterarse siempre de que algo se cortó. Con eso, una sincronización de ocho horas deja de ser un riesgo y pasa a ser simplemente un proceso más que corre de noche.