Controlar la concurrencia (límites de Cloud: Starter 5 / Pro 20 en paralelo)

En n8n Cloud, cada plan limita cuántas ejecuciones de flujo de trabajo pueden ejecutarse simultáneamente: el plan Starter permite 5 ejecuciones paralelas, el plan Pro 20, y el nivel Enterprise se sitúa, según la descripción general de precios de n8n, en 200 o más ejecuciones paralelas. Si se supera el límite, n8n pone automáticamente en cola las ejecuciones adicionales y las procesa según el principio FIFO en cuanto vuelve a haber capacidad disponible. Para empresas que procesan regularmente grandes volúmenes de datos, por ejemplo importaciones masivas, envíos masivos de correo o el procesamiento de listas largas mediante disparadores webhook, este límite es un factor que conviene conocer antes de construir un flujo de trabajo, de lo contrario las ejecuciones se acumulan sin ser notadas en la cola. Actualizado: julio de 2026.

Cómo funciona el límite de concurrencia en n8n Cloud

La limitación se aplica, según la documentación de n8n sobre concurrencia en la nube, exclusivamente a las ejecuciones de producción, es decir, aquellas iniciadas mediante un webhook o un nodo disparador. Las ejecuciones de prueba manuales, los subflujos de trabajo y los flujos de trabajo de error no cuentan y siguen ejecutándose independientemente del límite. Si el número de ejecuciones de producción simultáneas supera el valor del plan, las ejecuciones adicionales no se rechazan, sino que esperan en una cola. Importante en la práctica: las ejecuciones en espera no se pueden reintentar, y quien cancela una ejecución en espera la elimina por completo de la cola. Tras un reinicio de la instancia, n8n reanuda las ejecuciones en espera hasta el límite de capacidad y vuelve a poner en cola el resto. El nivel de uso actual se puede ver directamente en la pestaña de ejecuciones de un proyecto o flujo de trabajo.

Impacto en el procesamiento masivo

Por ejemplo, quien activa 500 registros individualmente como ejecuciones separadas a través de un webhook obtiene automáticamente una cola en el plan Starter después de las primeras 5 ejecuciones simultáneas, incluso si n8n en sí no muestra ningún mensaje de error. Esto retrasa el procesamiento general, pero no implica pérdida de datos, siempre que nadie cancele las ejecuciones en espera. Se vuelve más crítico en procesos sensibles al tiempo, por ejemplo cuando un sistema externo espera una respuesta rápida y la cola alarga de forma impredecible el tiempo de respuesta. También en los reinicios de instancia (por ejemplo, por ventanas de mantenimiento) la cola puede acumularse brevemente antes de procesarse.

Soluciones alternativas mediante batching

En lugar de activar muchas ejecuciones de producción individuales en paralelo, la carga se puede gestionar dentro de un único flujo de trabajo. Enfoques habituales en la práctica:

• Usar Split in Batches: los registros se procesan en grupos dentro de una sola ejecución de flujo de trabajo, en lugar de iniciar una ejecución de producción independiente para cada registro. Esto reduce notablemente el número de ejecuciones simultáneas.
• Planificar tiempos de espera: un nodo Wait entre lotes alivia los sistemas posteriores (por ejemplo, APIs con sus propios límites de tasa) además de la cola interna de n8n.
• Usar subflujos de trabajo: dado que las ejecuciones de subflujos de trabajo, según la documentación, no cuentan para el límite de concurrencia, la lógica de procesamiento se puede estructurar en parte de modo que se generen menos ejecuciones de producción de nivel superior simultáneas.
• Reducir la frecuencia de los disparadores: en cargas masivas, conviene ajustar el ritmo del proceso que dispara (por ejemplo, una tarea cron o una importación previa) para que mantenga desde el principio el número de llamadas webhook simultáneas por debajo del límite del plan.

Sinceramente, ninguno de estos trucos sustituye a un plan superior si se necesita de forma permanente más paralelismo real. El batching desplaza la carga en el tiempo, pero no crea capacidad adicional.

Autoalojado: control total sobre el límite

Quien opera n8n por su cuenta tiene más margen de maniobra: según la documentación de n8n sobre control de concurrencia, la limitación está desactivada de forma predeterminada en el autoalojamiento y se puede establecer específicamente mediante la variable de entorno N8N_CONCURRENCY_PRODUCTION_LIMIT, también en modo cola. Esto significa más control sobre la propia infraestructura, pero también más responsabilidad propia: sin un límite establecido conscientemente, una instancia puede sobrecargarse ante un pico de carga repentino. Precisamente aquí es donde entra una planificación adecuada, por ejemplo, a la hora de decidir si un plan Cloud o una infraestructura propia se ajusta al volumen de datos real y a los requisitos de control de una empresa. NordFlux apoya precisamente esta evaluación en el marco de su consultoría de n8n.

Preguntas frecuentes sobre el control de concurrencia en n8n

¿Qué ocurre con las ejecuciones que superan el límite?

No se descartan, sino que se colocan automáticamente en una cola y se procesan en el orden de llegada (FIFO) en cuanto vuelve a haber capacidad disponible.

¿El límite también se aplica a las ejecuciones de prueba manuales?

No. Según la documentación, el límite de concurrencia en n8n Cloud solo afecta a las ejecuciones de producción mediante webhook o nodo disparador. Las ejecuciones manuales, los subflujos de trabajo y los flujos de trabajo de error quedan excluidos.

¿Puedo simplemente reiniciar una ejecución en espera?

No, las ejecuciones en espera no se pueden reintentar. Quien las cancela las elimina por completo de la cola, y luego deben volver a activarse.

¿Merece la pena actualizar al plan Pro por el límite de concurrencia?

Depende del volumen de procesamiento real. Quien necesita regularmente bastante más de 5 ejecuciones de producción simultáneas notará con más frecuencia retrasos por la cola en el plan Starter. El batching puede amortiguar esto, pero para un volumen permanentemente alto no sustituye a un plan superior.