Hola,
Estoy experimentando problemas recurrentes de “conexión perdida” / “sin conexión” mientras uso n8n Cloud a través de la interfaz web, y me gustaría reportar el problema porque no parece ser causado por mi configuración o conexión a internet.
Mis flujos de trabajo son relativamente simples:
- No tengo una gran cantidad de flujos de trabajo
- Los flujos de trabajo no son especialmente largos ni complejos
- La mayoría son flujos de trabajo de scraping/automatización programados
- El problema ocurre frecuentemente alrededor de nodos HTTP Request
Lo que sucede es:
mientras se ejecuta un flujo de trabajo, la interfaz de repente muestra “Sin conexión” o pierde la conexión a veces la ejecución se detiene con mensajes relacionados con memoria o ejecución interrumpida. A pesar de eso, siempre es después de perder la conexión y sin embargo, si ejecuto los mismos flujos de trabajo manualmente uno por uno, generalmente se completan exitosamente
Ya rediseñé mi arquitectura para reducir la carga:
- Separé los flujos de trabajo en lugar de encadenar muchos subflujos de trabajo juntos
- Agregué reintentos solo en nodos de API externa
- Reduje la complejidad de la ejecución
- Intercalé los tiempos de ejecución entre flujos de trabajo
Incluso después de estas optimizaciones, sigo experimentando ocasionalmente pérdidas de conexión aleatorias.
Ya que estoy usando n8n Cloud directamente desde el navegador, me gustaría saber:
- Si este es un problema conocido
- Si hay limitaciones de estabilidad en el plan Starter
- O si hay alguna configuración recomendada para prevenir estas desconexiones
Gracias por tu ayuda.
Describe el problema/error/pregunta
¿Cuál es el mensaje de error (si hay alguno)?
Por favor, comparte tu flujo de trabajo
(Selecciona los nodos en tu lienzo y usa los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Comparte el resultado devuelto por el último nodo
Información sobre tu configuración de n8n
- Versión de n8n:
- Base de datos (por defecto: SQLite):
- Configuración de n8n EXECUTIONS_PROCESS (por defecto: own, main):
- Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
- Sistema operativo:
bienvenido a la comunidad de n8n @Raul_Martin_Acebes
Primero separaría el mensaje “offline” del navegador de la ejecución del workflow en sí, evitando ejecutar estos workflows desde el editor para trabajos de scraping largos. Mantenlos activos en Schedule Trigger, y luego consulta el historial de ejecuciones después de que terminen. Si el navegador se desconecta pero la ejecución continúa, es principalmente un problema de UI/sesión.
Para las partes de HTTP Request, añadiría batch/paginación y fragmentos más pequeños en lugar de extraer demasiados datos en una sola solicitud. La documentación de n8n menciona usar batching para reducir el tamaño de la solicitud y añadir pausas entre llamadas. También almacena el progreso entre pasos, para que una ejecución fallida pueda reanudarse en lugar de empezar desde cero.
Si las ejecuciones se detienen realmente con errores de memoria/interrumpidos, capturar el ID de ejecución, marca de tiempo, nombre del workflow y nodo que falla, y luego compara si siempre sucede con el mismo tamaño de respuesta HTTP o endpoint.
¡Bienvenido a la comunidad @Raul_Martin_Acebes! La configuración que describiste es reflexiva y claramente ya has hecho un buen trabajo aislando el problema.
Basándome en lo que dijo @tamy.santos, quiero añadir algunas cosas más específicas para los flujos de web scraping de n8n Cloud:
1. n8n Cloud tiene límites de tiempo de ejecución
En el plan Starter, los flujos se agotan después de 1 hora. Si tus flujos de scraping acceden a múltiples endpoints en bucles, pueden alcanzar silenciosamente este límite y detenerse. El navegador mostrando “sin conexión” es a menudo solo la sesión de WebSocket cayendo, pero el verdadero culpable es el tiempo de ejecución agotado. Comprueba tu historial de ejecuciones en Settings > Executions para ver si muestran “Error” con un mensaje de timeout.
2. Añade un nodo Wait entre las llamadas HTTP Request
Para flujos de scraping, añade un nodo Wait (configurado a 1-2 segundos) entre lotes de llamadas HTTP. Esto previene picos de memoria y reduce la probabilidad de que una única solicitud pesada bloquee el ejecutor:
Loop > HTTP Request > Wait (1s) > next iteration
3. Usa la opción “Continue on fail” en los nodos HTTP Request
Con “Continue on fail” habilitado + “Always Output Data” marcado, una única solicitud fallida no matará toda la ejecución. Puedes filtrar elementos fallidos después.
4. Divide los trabajos de scraping grandes en ejecuciones programadas más pequeñas
En lugar de un flujo que haga scraping de 1000 elementos, divide en lotes de 100-200 por ejecución con un Schedule Trigger cada 15 minutos. Mucho más estable en Cloud.
¿Puedes compartir aproximadamente cuántas solicitudes HTTP hay en una única ejecución de flujo y en qué plan estás? Eso me ayudará a acotar esto.
Muchas gracias por las sugerencias.
Implementé agrupamiento (batching) con nodos Loop Over Items + Wait y los flujos de trabajo definitivamente son más estables ahora. Desde que lo hice, ya no se despublica automáticamente y la mayoría de las ejecuciones se completan correctamente incluso cuando fallan algunos elementos.
Sin embargo, todavía ocasionalmente veo otro problema que parece no estar relacionado con la memoria/carga del flujo de trabajo:
-
El editor de repente muestra “Offline” incluso si no estoy ejecutando ningún flujo de trabajo.
-
A veces recibo errores 502 aleatorios como:
-
Durante ese tiempo pierdo temporalmente el acceso a la lista/interfaz de flujos de trabajo
-
Esto también puede suceder cuando no se está ejecutando ningún flujo de trabajo
Así que en este punto parece más un problema de inestabilidad en la Cloud/interfaz/sesión/backend que los flujos de trabajo agotando memoria.
¿Sabes cuál es la causa de esto? Me ocurre con frecuencia durante el día y tengo una buena conexión a internet.
@Raul_Martin_Acebes
Parece ser más bien una falla temporal entre el navegador, frontend, backend de n8n y proxy/cloud, o alguna inestabilidad del propio entorno Cloud. Intentaría capturar la hora exacta del problema, errores de la consola/network del navegador y validar si esto también ocurre en otro navegador o ventana anónima. Si aun así presenta error, enviaría esa información al soporte, porque ellos pueden verificar los logs de backend/proxy relacionados con los errores 502 de su lado.
¿Cómo me pongo en contacto con soporte? He estado intentando resolver el error y no he podido.
Aquí están sucediendo dos cosas diferentes, y vale la pena separarlas porque una de ellas probablemente no sea un problema real.
El banner “Offline” en el editor es simplemente tu navegador perdiendo su conexión en vivo a n8n Cloud — el WebSocket que transmite el progreso de la ejecución a la interfaz. No detiene la ejecución. Las ejecuciones programadas se ejecutan del lado del servidor tanto si tu pestaña está conectada como si no, así que puedes ignorar en gran medida el ruido “se fue offline”. La parte que realmente importa son los errores de memoria / ejecución interrumpida.
Eso huele a alcanzar el límite de memoria, que en el plan Starter es bastante bajo. El scraping es el desencadenante clásico: una HTTP Request extrayendo una página HTML completa o una respuesta JSON grande mantiene todo en memoria, y si eso se lleva a través de varios nodos descendentes — o un par de ejecuciones programadas se superponen — te excedes del límite y la ejecución se cancela. Esto también explica por qué ejecutarlas manualmente una a la vez funciona: sin superposición, pico de memoria bajo.
Lo que intentaría, en orden:
- Justo después de cada HTTP Request, coloca un nodo Set/Edit Fields (o un pequeño nodo Code) que mantenga solo los campos que realmente necesitas y descarte la respuesta sin procesar. Arrastrar el cuerpo de la página completa a través de todo el flujo de trabajo es lo que normalmente consume la memoria.
- Procesa en lotes — Loop Over Items / Split in Batches — en lugar de extraer y mantener todo a la vez. Mantiene el pico de memoria plano.
- Asegúrate de que dos ejecuciones programadas no puedan superponerse. El escalonamiento ayuda, pero si una ejecución toma más tiempo que el intervalo hasta el siguiente desencadenador, se apilan. Amplía los intervalos.
Si haces todo eso y aún así tienes problemas, entonces es genuinamente el plan — Pro ofrece más espacio para RAM. Pero yo reduciría primero el tamaño de la carga útil; los flujos de scraping casi siempre se reducen mucho una vez que dejas de llevar la respuesta sin procesar.