Si tu negocio usa n8n para automatizar tareas y lo tiene instalado en un servidor propio, quizá ya te pasó: alguien actualiza o reinicia el servidor y una automatización que estaba a medio camino queda marcada como fallida. Un pedido que no llegó a la hoja, un correo que no salió, un cliente que no pasó al CRM. Nadie se entera hasta que alguien pregunta.
La versión 2.43.7 de n8n, publicada el 16 de octubre de 2026, trae una opción para que eso no pase en un tipo concreto de instalación: en lugar de cortar la ejecución, n8n la pausa y otro servidor la retoma donde quedó. Es útil, pero no vale para todas las instalaciones ni para todos los flujos, y viene apagada. Te contamos a quién le sirve y cómo probarla antes de activarla.
- n8n 2.43.7 permite pausar las ejecuciones en curso cuando se apaga un servidor de trabajo y retomarlas en otro, en el siguiente paso del flujo.
- Solo aplica a instalaciones en modo cola (con servidores de trabajo separados) y viene desactivada. Hay flujos que quedan fuera, como las pruebas manuales o los que usan un chat.
- No reemplaza las alertas ni los reintentos: protege los reinicios planificados, no cualquier fallo. Conviene probarla primero en un entorno de pruebas.
Qué cambió en la versión 2.43.7
Las notas de la versión 2.43.7 tienen un único cambio: suspender las ejecuciones de producción en curso cuando un servidor de trabajo se apaga. El detalle está en el cambio que lo incorpora, integrado el 15 de octubre.
Para entenderlo hace falta un poco de contexto. Una instalación grande de n8n puede funcionar en lo que se llama modo cola: un servidor principal recibe los avisos (un formulario enviado, un pedido nuevo) y pone el trabajo en una fila, y otros servidores, los «workers» o servidores de trabajo, lo van tomando y ejecutando. Así se reparte la carga.
Hasta ahora, cuando uno de esos servidores de trabajo se apagaba para actualizarlo o reiniciarlo, tenía un margen para terminar lo que estaba haciendo (30 segundos por defecto, según la documentación). Lo que no terminaba a tiempo se cortaba y la ejecución quedaba fallida.
Con la nueva opción, el servidor que se apaga le pide a cada ejecución que se detenga al terminar el paso en el que está, guarda dónde quedó, y otro servidor la retoma desde ahí. Según el propio cambio, la reanudación puede tardar hasta un minuto aproximadamente.
A qué instalaciones afecta
La opción se activa con una variable de configuración, N8N_WORKER_, que viene en falso. Si nadie la cambia, todo sigue como antes. La documentación general de n8n todavía no la explica: el propio cambio deja la documentación como tarea pendiente. Hoy, la referencia es el código y su descripción.
Qué flujos quedan fuera
No todas las ejecuciones se pueden pausar. Según la descripción del cambio, quedan fuera:
- Las ejecuciones manuales y las evaluaciones, es decir, las pruebas que alguien lanza desde el editor.
- Las respuestas en tiempo real y las conexiones MCP (un protocolo para conectar herramientas de IA).
- Cualquier flujo que tenga un Chat Trigger activo, el nodo que inicia un flujo desde una conversación.
- Las ejecuciones cuyo resultado el servidor principal sigue esperando, por ejemplo una respuesta que todavía no se le devolvió a quien hizo la petición.
Y hay dos límites que conviene tener claros. La pausa ocurre entre pasos, no en medio de uno: si un paso tarda más que el margen de apagado, igual se corta. Y si una ejecución está trabada dentro de un paso (por ejemplo, esperando a un servicio que no responde), tampoco se puede pausar.
No es lo mismo que recuperar un fallo
Esta opción protege un caso concreto: el apagado ordenado de un servidor de trabajo. No sirve para:
- Errores del propio flujo, como un dato que falta o una API que devuelve un error.
- Caídas bruscas, como un servidor que se queda sin memoria o se corta la luz.
- Reintentos de negocio, como volver a intentar un pago o un envío que falló.
Para esos casos siguen haciendo falta alertas que avisen de un fallo y reintentos diseñados para no duplicar nada. Esta opción reduce un tipo de corte; no hace que una automatización sea a prueba de todo.
Cómo probarla antes de activarla
La prueba tiene que hacerse en un entorno de pruebas que copie tu instalación real, en modo cola y con al menos dos servidores de trabajo. Elige una automatización representativa: una que tenga varios pasos y que tarde lo suficiente como para poder apagar un servidor a mitad de camino.
- 1. AnotaAntes de apagar, registra qué ejecución está en curso, en qué paso va y qué resultado esperas al final.
- 2. ApagaCon la opción activada en los servidores de trabajo, apaga uno de forma ordenada mientras la automatización corre.
- 3. CompruebaMira si la ejecución quedó en espera y si otro servidor la retomó en el minuto siguiente.
- 4. ContrastaRevisa el resultado final: que esté completo, que no falte ningún paso y que nada se haya hecho dos veces.
El último punto es el más importante. Que la ejecución termine no basta: hay que comprobar que el correo salió una sola vez, que la fila se escribió una sola vez y que el pedido no se duplicó.
Cuándo activarla
Con la prueba hecha, la decisión es sencilla:
Si no usas modo cola, o si tus automatizaciones son cortas y casi nunca coinciden con un reinicio, no hace falta tocar nada.
Lo que no conviene hacer
- Activarla directamente en producción. Viene apagada por algo: primero, entorno de pruebas.
- Darla por documentada. Hoy la referencia es la descripción del cambio en el código. Si algo no queda claro, mejor preguntar a quien mantiene tu instalación.
- Tomarla como garantía. Pausa entre pasos y solo en apagados ordenados. Un paso largo o trabado se puede seguir cortando.
- Quitar las alertas de errores. Siguen siendo la forma de enterarte de lo que esta opción no cubre.
Si estás actualizando n8n, revisa también lo que cambió con los nodos obsoletos desde la versión 2.42.6. Y si todavía estás decidiendo qué tareas conviene automatizar, lo explicamos en automatizar procesos con IA: qué sí, qué no.
