Ejecución bloqueada: encontrar stuck executions, configurar timeouts

En n8n ves una ejecución que simplemente no termina. El estado se queda en «Running» o «Waiting» aunque el workflow debería haber terminado hace tiempo. Esto se llama una ejecución bloqueada o «stuck», y es más que un problema cosmético: de forma predeterminada, según la referencia oficial de variables de ejecución n8n no tiene ningún límite de tiempo, EXECUTIONS_TIMEOUT está en -1 de forma predeterminada. Sin una configuración propia, una ejecución puede teóricamente seguir corriendo de forma indefinida, bloqueando recursos, slots de worker y, en modo queue, colas enteras.

Este artículo te muestra cómo reconocer las ejecuciones bloqueadas, qué causas suelen estar detrás y cómo establecer, con EXECUTIONS_TIMEOUT y EXECUTIONS_TIMEOUT_MAX, un límite de tiempo limpio adaptado a tu instancia. Actualizado: julio de 2026.

¿Cómo reconoces las ejecuciones bloqueadas?

• En la pestaña «Executions», el estado permanece de forma persistente en «Running» o «Waiting», aunque ejecuciones comparables normalmente terminan en segundos o pocos minutos.
• El contador de duración sigue aumentando sin que se vean nuevas entradas de log ni cambios de nodo.
• En modo queue, las nuevas ejecuciones se acumulan en la cola porque un worker está bloqueado por la ejecución bloqueada y, según la configuración a través de N8N_CONCURRENCY_PRODUCTION_LIMIT, no puede iniciar más ejecuciones en paralelo.
• El servidor consume notablemente más memoria o CPU sin que esto se explique por la carga actual.

Una única ejecución bloqueada parece inofensiva al principio. En la práctica, sin embargo, basta con un puñado de estas ejecuciones para ralentizar notablemente toda una instancia de n8n, sobre todo cuando varios workflows comparten el mismo pool de workers.

Causas típicas de las ejecuciones bloqueadas

• Sin timeout configurado: sin tu propia configuración de EXECUTIONS_TIMEOUT no se aplica ningún límite automático, y un único nodo defectuoso puede mantener toda la ejecución abierta.
• Llamadas externas sin timeout propio: un nodo HTTP Request que espera una API muy lenta o que no responde se queda bloqueado hasta que el otro extremo reacciona o hasta que interviene el propio n8n.
• Nodos Wait mal configurados: un nodo Wait que espera un evento externo que nunca se produce mantiene la ejecución de forma permanente en el estado «Waiting».
• Sub-workflows bloqueados: si tu workflow principal llama a un sub-workflow, el bloqueo de este se transmite directamente a la ejecución superior.
• Problemas en modo queue: si la conexión entre el proceso principal y el worker se ve interrumpida, por ejemplo por un acceso a Redis inestable, las ejecuciones permanecen en el estado «Running» sin que el worker las siga procesando realmente.

Configurar correctamente EXECUTIONS_TIMEOUT y EXECUTIONS_TIMEOUT_MAX

Para un límite de tiempo fiable, según la guía de configuración de timeouts de workflow, dos variables de entorno son decisivas:

• EXECUTIONS_TIMEOUT: establece el límite de tiempo predeterminado en segundos, que se aplica a todos los workflows salvo que se haya definido un límite individual. El valor predeterminado es -1, es decir, desactivado. Un valor de 3600 limita cada ejecución a una hora.
• EXECUTIONS_TIMEOUT_MAX: define el límite absoluto en segundos, que se aplica incluso si un workflow individual ha establecido un timeout propio más alto. Según la referencia, el valor predeterminado es de 3600 segundos.

Importante para entender cómo actúa técnicamente el timeout: si el workflow se ejecuta en el proceso principal, según la documentación se produce un timeout suave, que solo actúa una vez finalizado el nodo actualmente activo. Si, en cambio, la ejecución se realiza en un proceso separado, por ejemplo en modo queue en un worker, n8n intenta primero también una interrupción suave y después fuerza una interrupción dura. Para ti esto significa: un timeout no es un corte instantáneo, sino un mecanismo escalonado que finaliza el trabajo en curso de la forma más limpia posible antes de intervenir de forma dura.

Cada workflow puede definir en su propia configuración un timeout propio y más bajo. Sin embargo, este siempre queda limitado por arriba por EXECUTIONS_TIMEOUT_MAX, de modo que un workflow individual no puede superar el límite global. Así mantienes el control sobre la duración máxima sin tener que asegurar individualmente cada workflow.

Limpiar los datos de ejecución para mantener la base de datos ligera

Más allá del simple límite de tiempo, merece la pena echar un vistazo a la retención de los datos de ejecución, ya que una base de datos sobrecargada también dificulta el diagnóstico de las ejecuciones bloqueadas. Según la referencia, n8n limpia automáticamente los datos de ejecución:

• EXECUTIONS_DATA_PRUNE (predeterminado: activado) controla si las ejecuciones finalizadas se eliminan automáticamente.
• EXECUTIONS_DATA_MAX_AGE determina después de cuántas horas las ejecuciones antiguas se consideran candidatas para su eliminación; el valor predeterminado equivale a 14 días.
• Las ejecuciones activas con el estado «new», «running» o «waiting» quedan explícitamente excluidas de la limpieza, al igual que las ejecuciones a las que hayas añadido etiquetas o valoraciones.

Estos mecanismos de protección son un arma de doble filo: por un lado evitan que una ejecución aún en curso se elimine por error, pero al mismo tiempo hacen que una ejecución realmente bloqueada permanezca de forma permanente en la base de datos mientras ningún timeout la finalice de forma regular. Precisamente por eso es importante la combinación de un EXECUTIONS_TIMEOUT razonable y una limpieza de datos que funcione, para que las ejecuciones bloqueadas no se acumulen sin ser detectadas.

Checklist práctica

• Comprueba primero en la pestaña Executions qué ejecuciones llevan realmente horas o días en «Running» o «Waiting».
• Establece EXECUTIONS_TIMEOUT en un valor realista para tus workflows regulares más largos, más un margen de seguridad.
• Establece EXECUTIONS_TIMEOUT_MAX de forma que ni siquiera los workflows individuales especialmente largos puedan ejecutarse indefinidamente.
• En los nodos conectados a servicios externos, como HTTP Request o puntos de espera Webhook, comprueba si tiene sentido añadir allí un timeout propio.
• En modo queue, vigila también la conexión con Redis y la carga de tus workers, ya que un worker bloqueado provoca síntomas muy distintos a los de un único workflow bloqueado.

Si utilizas n8n como un empleado digital en tu empresa, un timeout correctamente configurado forma parte del equipamiento básico, al igual que vigilar los límites de concurrency y la limpieza de datos. Una vez que ajustas correctamente estos parámetros, normalmente ya no tienes que ocuparte manualmente de las ejecuciones bloqueadas. Si necesitas apoyo con esto o quieres que tu instancia de n8n sea fundamentalmente más estable, NordFlux te apoya en la configuración y operación de workflows de n8n.

Preguntas frecuentes

¿Qué significa el estado «Waiting» en una ejecución de n8n?

«Waiting» indica que la ejecución está esperando, en algún punto del workflow, un evento externo, por ejemplo una respuesta de un nodo Wait o una llamada webhook pendiente. Si este estado persiste más allá de la duración esperada, indica un evento que nunca llega, y la ejecución queda efectivamente bloqueada hasta que un timeout la finaliza.

¿Qué valor debería establecer para EXECUTIONS_TIMEOUT?

No existe un valor universalmente correcto, depende de tus workflows regulares más largos. Como punto de partida, resulta útil medir la duración normal de tu automatización más exigente y redondearla generosamente, por ejemplo entre dos y tres veces. Así queda suficiente margen para las fluctuaciones normales, mientras que las ejecuciones realmente bloqueadas siguen finalizándose de forma fiable.

¿EXECUTIONS_TIMEOUT finaliza una ejecución de inmediato?

No, según la documentación de n8n, primero se produce una interrupción suave. En el proceso principal, n8n espera a que finalice el nodo actualmente en ejecución; en procesos separados, tras un intento suave, se fuerza además una interrupción dura tras un breve tiempo de espera. La transición es, por tanto, escalonada y no abrupta.

¿Puede un workflow individual tener un timeout más alto que el permitido por EXECUTIONS_TIMEOUT_MAX?

No. EXECUTIONS_TIMEOUT_MAX define el límite absoluto para toda la instancia. Aunque un workflow haya establecido en su propia configuración un timeout individual más alto, este valor queda limitado por EXECUTIONS_TIMEOUT_MAX, de modo que ningún workflow puede superar el límite global.

¿Se eliminan automáticamente de la base de datos las ejecuciones bloqueadas?

No mientras estén activas. n8n excluye explícitamente de la limpieza automática mediante EXECUTIONS_DATA_PRUNE las ejecuciones con el estado «new», «running» o «waiting». Por eso, una ejecución realmente bloqueada permanece hasta que un timeout configurado la finaliza o hasta que la cancelas manualmente.