Hola a todos,
Espero que alguien pueda ayudarme o al menos orientarme en la dirección correcta.
Mi espacio de trabajo de n8n Cloud ha estado offline durante más de una hora con la clásica pantalla 503 “workspace is restarting” mientras que dice que mi instancia está en línea. Tengo una demostración de este flujo de trabajo para presentar muy pronto.
Qué pasó: Ejecuté mi flujo de trabajo por primera vez, involucra un disparador de Gmail descargando archivos PDF adjuntos + 3 nodos de agentes de IA (Claude/Anthropic). Parece que alcanzó el límite de memoria en la primera ejecución y el espacio de trabajo simplemente nunca volvió a estar disponible.
Lo que ya he intentado:
-
Esperar, actualizar, diferentes navegadores, incógnito — sigue siendo 503
-
Comprobar status.n8n.cloud — sin incidentes globales
-
Reiniciar manualmente la instancia.
-
Contactar al soporte — recibí una respuesta de un bot de IA diciéndome que “optimice mi flujo de trabajo”. He pedido escalar a un humano pero sin respuesta aún.
La parte frustrante: Sé cuál es la solución (reducir límites de tokens, manejar los adjuntos de manera diferente) — simplemente no puedo acceder al editor para aplicarla porque el espacio de trabajo está caído.
¿Alguien ha pasado por esto y encontró una manera de poner la instancia en funcionamiento nuevamente sin esperar al soporte? ¿Hay alguna forma de forzar un reinicio desde el panel de administrador que me esté perdiendo?
Qualquier ayuda será enormemente apreciada 
Información sobre mi configuración de n8n:
Por favor, obtén ayuda de help@n8n.io
@PaulRocks El error 503 stuck-loop generalmente significa que tu pod está agotando memoria (OOMing) al reiniciar porque el flujo de trabajo fallido se ejecuta automáticamente cuando n8n lo trae de vuelta — se bloquea, reintenta, se bloquea nuevamente. ¿Has intentado el ciclo Suspend → Resume en tu admin de app.n8n.cloud? Es el único force-restart de autoservicio que expone la nube, y el paso suspend evita la ejecución automática para que el pod pueda levantarse limpiamente antes de que se ejecute cualquier flujo de trabajo.
gracias por la recomendación. Intenté el botón Restart workspace desde el panel Manage pero mismo resultado, sigue atrapado en el bucle 503. Confirma lo que dijiste sobre que el pod se bloquea al reiniciarse antes de que pueda cargar nada.
Honestamente estoy considerando simplemente crear una nueva cuenta de n8n Cloud y reconstruir el workflow desde cero para cumplir mi fecha de demostración esta semana, pero me costará una segunda suscripción. No es ideal pero se me están agotando las opciones.
O tal vez actualizar el plan actual sea el único arreglo real aquí ya que habrá 640 MIB?
¿Cuánto tiempo, en general, tarda el soporte de N8N en responder? Si es en un día, podría esperar. Si es en dos o más días, será muy complicado para mí.
@PaulRocks no hagas upgrade ni crees una cuenta nueva todavía, el soporte generalmente puede reiniciar el pod. envía un email a help@n8n.io con tu URL de instancia y “URGENT 503 crash loop” en el asunto, menciona que ya sabes que el workflow es la causa del OOM y solo necesitas que reinicien el pod con el workflow inactivo al reanudar. así no se bloquea inmediatamente y puedes arreglarlo antes de reactivarlo.
la presión de memoria es el verdadero problema de fondo — la descarga de adjuntos de gmail + 3 nodos de IA acumulándose en memoria es pesado para starter. una vez que vuelvas, o aligeramanejo de adjuntos o sube el plan. prueba primero, optimización después.
Actualización: está de vuelta 
Gracias por la ayuda
Una pregunta rápida ahora — ¿qué debería modificar en el workflow para asegurarme de que esto no vuelva a suceder en Starter (320 MiB)?
Configuración actual:
-
Gmail Trigger con downloadAttachments: true (11 PDFs)
-
3 agentes secuenciales de Anthropic Claude (maxTokens configurado a 4096 y 8192)
-
Structured output parsers en 2 de los 3 agentes
-
El workflow pasa todos los datos a través de la cadena
Mencionaste que deshabilitar downloadAttachments y hacer streaming a través del endpoint binario en su lugar — ¿podrías explicar cómo funciona eso en la práctica? ¿Solo hago referencia a los adjuntos por ID más tarde cuando realmente necesito leerlos?
También estoy abierto a cualquier otro consejo de optimización de memoria para workflows con muchos datos de IA en Cloud. Gracias de nuevo
sí exacto — desactiva downloadAttachments en el disparador de Gmail para que se dispare solo con metadatos (ID de mensaje + ID de adjunto + nombre de archivo). después añades un nodo de Gmail “Get a Message Attachment” dentro de un bucle SplitInBatches con tamaño de lote 1, solo un PDF en memoria a la vez en lugar de los 11 apilados.
dos cosas más para intentar. reduce maxTokens de 4096/8192 a 1024-2048 a menos que genuinamente necesites esa longitud, reduce mucha memoria por cada llamada del agente. y coloca un nodo Set después de cada paso de IA que conserve SOLO el campo que necesitas de ahora en adelante — n8n transmite todos los datos de entrada a través de cada nodo por defecto así que cada salida del agente se apila encima de cada payload anterior.