Ejecución del flujo de trabajo detenida forzadamente por n8n después de 3-6 horas sin error claro en ningún nodo

He publicado mi automatización. El disparador es un nodo webhook, cuando se envía un CSV (1000 leads) a ese webhook se inicia la automatización, pero n8n fuerza la terminación de la automatización, la primera vez se ejecutó durante 3 horas (procesó 260 leads) antes de ser forzada a terminar y en el siguiente intento se ejecutó durante 6 horas [comenzó desde el principio y procesó 500 leads] antes de ser forzada a terminar:

Estoy intentando una tercera vez con configuraciones diferentes que son:

Por favor, háganme saber si alguien conoce la causa probable y la solución

Hola @AbdullahShah, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@alexm, @Mark_Tic, @Niffzy - han ayudado con problemas similares antes, ¿pueden echar un vistazo?

Sugerido automáticamente por el bot de comunidad de n8n. Es una prueba piloto - por favor comparte comentarios aquí.

Dos cosas que puedes descartar o confirmar directamente desde tus propias capturas de pantalla.

No es el tiempo de espera del flujo de trabajo. Tu captura de pantalla de configuración muestra “Timeout Workflow” desactivado, así que n8n no está terminando la ejecución por un límite de tiempo. Además, la forma es incorrecta para un tiempo de espera — las dos ejecuciones terminaron a las 3h15m y 6h17m, no en el mismo punto.

“Save execution progress” está activado. Eso hace que n8n escriba el estado de ejecución después de cada nodo. A lo largo de una ejecución que itera 1000 clientes potenciales, ese es un número muy grande de escrituras acumulándose contra un registro de ejecución, y es un contribuyente común a que una ejecución larga crezca hasta que el proceso sea eliminado en lugar de que un nodo falle. Esa distinción coincide con tu síntoma: una ejecución que termina sin error en ningún nodo normalmente significa que el proceso murió, no que algo lanzó una excepción. Desactivar esa configuración es lo más económico de probar, y lo único que pierdes es la capacidad de reanudar una ejecución fallida desde la mitad.

Vale la pena señalar que tu rendimiento fue constante ambas veces — 260 clientes en 3h15m y 500 en 6h17m es aproximadamente 45 segundos por cliente de cualquier forma. Nada se degradó antes del final. Se detuvo en lugar de ralentizarse, lo que nuevamente apunta a que el proceso fue eliminado.

Una cosa que es fácil pasar por alto, y ya ha sucedido. Tu segunda ejecución comenzó desde el principio y llegó a 500. La primera ya había alcanzado 260. Si esos nodos envían correos electrónicos, los primeros 260 clientes recibieron el mismo correo frío dos veces. Nada en n8n señala eso — el reintento se ve limpio y los envíos duplicados no aparecen como errores en ningún lugar. Antes del siguiente intento, vale la pena escribir cada cliente en una hoja o tabla en el momento en que se envía, y verificar esa lista antes de enviar, para que un reinicio reanude en lugar de repetir. En prospección fría, el envío duplicado generalmente cuesta más que lo que costó la ejecución fallida.

Divulgación: Usé Claude para ayudar a elaborar esto. Las dos observaciones sobre configuración se leen directamente de las capturas de pantalla que publicaste. La explicación de memoria es la causa más probable dado el síntoma, no algo verificado contra tu instancia, y no lo verifiqué contra la documentación mientras escribía. Estoy feliz de ser corregido si tu configuración lo descarta.

ambos los fallos ocurrieron antes de que activara la opción „guardar progreso de ejecución", esa configuración no pudo haber causado las ejecuciones #1 y #2. Podría empeorar ligeramente las cosas ahora, pero no es lo que mató las dos ejecuciones originales

Hola @AbdullahShah

Tu flujo de trabajo casi con certeza está experimentando un colapso por falta de memoria (OOM) porque n8n intenta mantener los datos de ejecución de los 1000 contactos en la RAM simultáneamente en todos los nodos durante una ejecución de varias horas.

Tienes Guardar progreso de ejecución configurado en Guardar.

  • La solución: Cambia esto a Predeterminado - NO GUARDAR.

  • La razón: Cuando esto está habilitado, n8n escribe el estado de cada nodo individual en la base de datos continuamente durante la ejecución. Para una ejecución de 3 a 6 horas, esto crea un cuello de botella masivo, aumentando tanto la RAM como tu base de datos PostgreSQL/SQLite hasta que el proceso de Node.js falla o el contenedor es eliminado por el host.

Ejecutar 1000 iteraciones pesadas en un único flujo de trabajo eventualmente agotará la memoria del montón de Node.js porque el recolector de basura no puede limpiar los datos hasta que toda la ejecución principal se complete.

  • La solución: Usa un nodo Execute Workflow para pasar los contactos a un flujo de trabajo secundario en lotes más pequeños.

  • La razón: Cuando un subflujo de trabajo se completa, n8n vacía sus datos de ejecución de la memoria, manteniendo la huella de RAM del flujo de trabajo principal pequeña.

Tienes razón, y mi publicación fue incorrecta en eso. Tu primer mensaje dice que la tercera ejecución es la que tiene la nueva configuración, así que el progreso de ejecución guardado no estaba activado para las ejecuciones #1 y #2 y no puede explicarlas. Interpreté esa captura de pantalla como tu estado actual en lugar de tu estado modificado. Ignora esa parte.

Lo que aún se mantiene, según tus propios números:

El tiempo de espera del flujo de trabajo sigue siendo descartado. Timeout Workflow está desactivado, y las dos ejecuciones terminaron a las 3h15m y 6h17m en lugar de en la misma marca.

El rendimiento fue constante hasta el final ambas veces. 260 clientes potenciales en 3h15m y 500 en 6h17m es aproximadamente 45 segundos por cliente potencial en ambas ejecuciones. Se detuvo en lugar de ralentizarse primero, lo cual es la característica de un proceso siendo eliminado en lugar de un nodo lanzando una excepción o la ejecución degradándose.

Separado de la causa, una cosa que vale la pena verificar: la ejecución #2 se reinició desde el principio y alcanzó 500, mientras que la ejecución #1 ya había alcanzado 260. Si los correos electrónicos se envían dentro de ese bucle, aproximadamente los primeros 260 clientes potenciales fueron contactados dos veces, y nada lo señala porque la segunda ejecución se ve limpia por sí sola. Una verificación contra un campo ya contactado antes del paso de envío hace que un reinicio sea seguro para repetir.

Declaración: utilizo Claude para ayudar a redactar estos mensajes. El punto del tiempo de espera y la aritmética del rendimiento se leen de tus capturas de pantalla y tus números indicados. No he verificado la documentación de n8n ni tu instancia, y cometí un error en la línea de tiempo de configuración anterior, así que pesa en consecuencia.

Tanto @kjooleng como @ClearStack acertaron de lleno respecto al crash OOM y el peligro de envíos de correo duplicados.

Cuando procesas 1000 elementos en una única ejecución lineal o bucle, Node.js acumula todos los estados de entrada/salida del nodo en memoria. El Garbage Collection no puede limpiar objetos hasta que se complete toda la ejecución del flujo de trabajo padre, lo que provoca terminaciones OOM en el host.

Aquí está el patrón de producción de 3 pasos para resolver tanto la fuga de memoria como el riesgo de correos duplicados:

### 1. El Patrón de Agrupamiento por Subflujos (Resuelve OOM)

En lugar de ejecutar los 1000 clientes potenciales en un único bucle en el flujo de trabajo padre:

1. Usa un **Nodo Split In Batches** (tamaño de lote: 50-100 elementos).

2. Pasa cada lote a un flujo de trabajo secundario usando el **Nodo Execute Workflow**.

3. **Por qué funciona:** Cuando cada ejecución de subflujo termina, n8n inmediatamente vacía su huella de RAM y activa el Garbage Collector de Node.js, manteniendo el uso de memoria plano durante una ejecución de 6 horas.

### 2. Verificación de Idempotencia (Previene Spam de Correos Duplicados)

Como señaló @ClearStack, si la ejecución #1 falla en el cliente potencial 260 y reinicia, los clientes potenciales 1-260 reciben correo electrónico dos veces.

* Dentro de tu subflujo, justo antes del Nodo Email Send, añade un **Nodo If / Filter** que verifique `already_contacted === true` (o consulte tu BD para `email_sent_at IS NOT NULL`).

* Si `true` → Omitir.

* Si `false` → Envía correo electrónico e inmediatamente actualiza el estado de la BD a `contacted`.

### 3. Aumenta el Límite de Heap de Node.js (Si es Autohospedado / Docker)

Si estás autohospedando n8n mediante Docker o PM2, el límite de memoria de heap de Node.js por defecto es alrededor de 2GB. Para trabajos por lotes de larga duración, aumentalo en tus variables de entorno:

```bash

NODE_OPTIONS=“–max-old-space-size=4096”

```

*(Esto asigna hasta 4GB de RAM al proceso n8n).*

Combinar **Subflujos + Agrupamiento + Verificaciones de Idempotencia Previa al Envío** es la forma estándar de ejecutar canalizaciones de 10k+ clientes potenciales sin bloquear n8n o enviar spam a usuarios.

Hola @AbdullahShah
Segun los badges de Upgrade en tu captura de pantalla de configuración, estás en Cloud, donde el límite es mucho más bajo que un proceso Node predeterminado: Trial y Starter obtienen 320MiB, Pro-1 640MiB, Pro-2 1280MiB, y n8n en sí consume alrededor de 180MiB de eso antes de que se inicie tu ejecución. Una ejecución que permanece abierta durante seis horas en 1000 contactos no cabe en lo que queda.
Saca toda la lista de una única ejecución. Haz que el webhook escriba las 1000 filas en una hoja o tabla con una columna status y termina allí, luego impulsa el envío desde un Schedule Trigger que extrae las primeras 25 filas donde status está vacío, realiza el trabajo y escribe sent. Cada ejecución dura un par de minutos y libera su memoria cuando termina, y un bloqueo cuesta un lote en lugar de toda la ejecución.

Si estás considerando si un plan más grande te proporciona suficiente margen, esto desglosa los niveles:

ok ahora estoy dividiendo mi flujo de trabajo en un subflujo para ver si esto resuelve el problema de OOM, ¿alguien puede aclarar una cosa, necesito publicar el subflujo también junto con el flujo de trabajo principal?
mi subflujo:

Sub1 Non-DNC(1).json (526.6 KB)

no te preocupes por contactar dos veces al mismo cliente potencial, ya que estoy integrando este flujo de trabajo con Instantly AI al final, así que Instantly AI automáticamente nunca mantiene duplicados

Sí, tanto el workflow principal como el subworkflow deben ser publicados


Solo quería cerrar este tema.

El flujo de trabajo original se estaba terminando forzosamente después de 3–6 horas sin error de nodo porque mantenía toda la ejecución de 1000 contactos en memoria todo el tiempo (clásico OOM en n8n Cloud).

Ahora lo he dividido: el flujo padre solo hace webhook → extracción CSV → Google Sheet → filtro DNC → Split In Batches (tamaño 1) → Execute Workflow. Todo el trabajo pesado (investigación con Perplexity + 5× puntuación GPT-4 + generación de correos + envío con Instantly) está en dos sub-flujos publicados que procesan un contacto a la vez y liberan memoria cuando cada uno termina.

Actualmente estoy probando con 500 contactos.

Pregunta para la gente experimentada aquí: con esta arquitectura, ¿puedo enviar con seguridad un único CSV de 5 000–6 000 contactos a través del webhook, o debo seguir dividiendo la lista en archivos más pequeños (p. ej. 1 000 a la vez) incluso con el patrón de sub-flujo? ¿Hay algún límite práctico que deba respetar en Cloud?

Gracias de antemano.

Aunque los flujos de trabajo secundarios son eficientes en memoria, el flujo de trabajo principal no lo es. Cuando utilizas los nodos “Read Binary File” (CSV) y “Extract from File”, n8n convierte ese CSV en un enorme array JSON en la memoria del flujo principal.

  • Un CSV de 6 000 filas podría ocupar solo 5 MB en disco, pero una vez que se analiza en un objeto JSON en n8n, podría crecer fácilmente a 200 MB–500 MB de RAM dependiendo de cuántas columnas haya y cuánto texto contenga cada celda.
  • El nodo “Split In Batches” también mantiene una referencia a todo el array original para seguir la pista de su índice.
  • El Riesgo: Si el CSV es grande o los datos son “pesados” (por ejemplo, descripciones largas), el flujo de trabajo principal en sí podría activar el OOM killer antes de llegar al primer subflujo.

Por lo tanto, la respuesta es NO

Una ejecución de 6 000 leads, procesando un lead a la vez con llamadas de IA pesadas (Perplexity + 5x GPT-4), va a tomar mucho tiempo (potencialmente 10–20+ horas dependiendo de la latencia).

  • El Problema: Si la instancia de n8n Cloud se somete a mantenimiento, o si hay un pequeño problema de red que interrumpe la ejecución del flujo principal, pierdes tu progreso.
  • Porque el “estado” de tu bucle (dónde estabas en el lote) se almacena en la RAM de esa ejecución específica, no puedes “reanudar” fácilmente desde el lead #3 402. Tendrías que reiniciar desde el lead #1, desperdiciando una cantidad masiva de créditos de API y tiempo.

En definitiva, 500 o 1 000 leads por disparo de CSV/Webhook es una opción más segura. Dividir los datos es el camino a seguir.

Solo quería cerrar este asunto.

El problema original era que n8n forzaba la detención del flujo de trabajo después de 3–6 horas sin ningún error en ningún nodo. Resultó ser un problema clásico de falta de memoria (OOM, Out of Memory) — n8n estaba manteniendo todos los datos de clientes potenciales procesados en memoria durante toda la duración de la ejecución.

La solución fue dividir el flujo de trabajo en subflujos de trabajo. Todo lo que venía después del nodo de bucle se movió a un subflujo de trabajo. De esta manera, el flujo de trabajo padre solo mantiene los datos de procesamiento actual en memoria, y el trabajo pesado (y los datos de clientes potenciales ya procesados) se libera tan pronto como cada subflujo de trabajo finaliza.

Con este cambio, la automatización ahora puede manejar cómodamente archivos CSV de 1000–2000 clientes potenciales, lo que es un gran salto respecto al máximo anterior de aproximadamente 300–400 clientes potenciales antes de alcanzar OOM.

Un enorme agradecimiento a todos en esta comunidad que ayudaron a diagnosticar y me señalaron en la dirección correcta. Realmente agradecido por el apoyo… Que Dios los bendiga a todos, ¡gracias hermanos!