Cambio de hora en n8n: zonas y horarios

Un flujo que parece haberse ejecutado una hora antes o después de lo esperado no demuestra, por sí solo, un fallo de n8n. Puede intervenir la zona horaria configurada para el flujo, la de la instancia o la propia regla de programación. En su documentación del nodo Schedule Trigger, n8n explica que el disparador utiliza la zona del flujo si está definida y, en caso contrario, la zona de la instancia. También distingue horarios concretos de intervalos y expresiones Cron. Revisar esas tres piezas ofrece una explicación comprobable antes de modificar un flujo en producción.

Ilustración conceptual generada con IA por Gaia Genius Hub. La pantalla no muestra una instancia ni un flujo real de n8n.

Esta guía se basa en la documentación pública de n8n consultada el 29 de octubre de 2026. No hemos accedido a una instancia del lector ni ejecutado un flujo de prueba. Si buscas una introducción a la herramienta antes de revisar horarios, consulta cinco flujos de n8n para principiantes. Los detalles de planificación dependen de la versión y de cómo esté configurado el planificador, así que conviene registrar ambos antes de atribuir un comportamiento al cambio estacional de hora.

Qué zona horaria utiliza el disparador

La prioridad descrita por n8n es sencilla: primero, la zona configurada en el flujo; después, la zona de la instancia. El ajuste individual está en el menú del flujo, dentro de Settings → Timezone, según la guía de configuración de flujos y la página de problemas habituales de Schedule Trigger. Si un equipo comparte una instancia, conviene mirar este ajuste antes de dar por supuesta la zona que aparece en el perfil personal de quien abre el editor.

Cuando el flujo no tiene una zona propia, importa la configuración de la instancia. Para una instalación autogestionada, n8n documenta la variable GENERIC_TIMEZONE, cuyo valor predeterminado indicado es America/New_York. En n8n Cloud, la documentación del disparador indica que se intenta detectar la zona del propietario al registrarse y que, si eso falla, se usa GMT. El propietario de la instancia Cloud puede cambiarla en la consola, en Instance settings → Runtime → Time zone; n8n advierte que guardar ese cambio reinicia la instancia (configuración de Cloud).

Por ejemplo, si se pretende que una tarea se ejecute a las 09:00 de Madrid, anotar «09:00» sin su zona deja un dato incompleto. Europe/Madrid expresa la hora civil de ese lugar; su equivalencia en UTC cambia con la estación. Este es un ejemplo de documentación, no la comprobación de que un flujo concreto haya disparado a esa hora. En la interfaz hay que confirmar la zona realmente guardada y la fecha de la ejecución.

Un horario fijo no se revisa igual que «cada treinta minutos»

El nodo permite reglas por segundos, minutos, horas, días, semanas, meses o una expresión Custom (Cron). También admite varias reglas en un mismo disparador (parámetros de Schedule Trigger). Si la intención es «todos los días a una hora local», la revisión debe centrarse en la hora, la zona y los días elegidos. Si la intención es «cada N minutos», hay que comprobar desde qué momento se mide ese intervalo.

Aquí la versión importa. Según n8n, desde 2.45.0 el planificador duradero está activo por defecto y los intervalos de N segundos o N minutos se cuentan, por defecto, desde la publicación del flujo, siempre que el servicio de publicación de flujos permanezca activo (es el valor predeterminado). Las reglas Custom (Cron) mantienen su patrón de calendario. La misma documentación explica que la opción heredada, cuando se usa, alinea esos intervalos con los límites del reloj; la diferencia no se aplica a todas las cadencias (planificador duradero). Por eso «cada 30 minutos» y «a los minutos 00 y 30 de cada hora» no son promesas intercambiables en todas las versiones y configuraciones.

Supongamos, solo como ejemplo, que un flujo con un intervalo de 30 minutos se publica a las 10:07 en una instancia 2.45.0 o posterior con el modo predeterminado: el siguiente intervalo se calcula desde ese momento, no necesariamente desde las 10:00. En cambio, una regla Cron escrita para minutos concretos se interpreta como tal. Antes de cambiar una regla, comprueba la versión instalada y el modo del planificador; no deduzcas la hora siguiente a partir de una captura antigua del editor (diferencias de planificación).

Una expresión Cron mal formada constituye otro problema. La guía oficial de incidencias recomienda revisar su sintaxis; n8n admite una columna opcional de segundos, de modo que una expresión de seis campos no se lee igual que una de cinco sin comprobar qué representa cada campo (ejemplos y orden de campos). No copies una expresión de otro sistema sin verificarla en este nodo.

Qué revisar antes y después de publicar el flujo

Una comprobación ordenada evita cambiar la zona horaria por intuición:

1. Anota la versión y la instalación. Distingue n8n Cloud de una instancia autogestionada. Desde 2.45.0, comprueba si se mantiene el planificador duradero predeterminado o si se configuró un modo heredado; las diferencias están documentadas por n8n.
2. Abre los ajustes del flujo. Revisa Timezone. Si está definido, será la zona que usa Schedule Trigger; si no, consulta la zona de la instancia (ajustes del flujo).
3. Lee todas las reglas del nodo. Apunta si son horas/días, intervalos o Cron, sus valores y los días seleccionados. Un nodo puede contener más de una regla (Schedule Trigger).
4. Guarda y publica la versión que quieres ejecutar. La documentación actual indica que los flujos con Schedule Trigger deben guardarse y publicarse. Cambiar un intervalo o el valor de una variable usada por Cron sin publicar una nueva versión puede dejar vigente la programación anterior (requisitos del nodo; problemas habituales). En instalaciones antiguas, verifica la interfaz y la documentación correspondientes a su versión antes de trasladar literalmente estos pasos.
5. Contrasta la siguiente ejecución real. Conserva la fecha, la zona esperada y el registro de ejecución. Una prueba manual confirma que el flujo puede ejecutarse manualmente, pero no demuestra por sí misma que el horario automático esté configurado como se esperaba. Si el caso afecta a un día de transición horaria, revisa las ejecuciones a ambos lados de esa fecha.

Si la instancia estuvo parada, el diagnóstico requiere un paso adicional. Los nodos Schedule Trigger añadidos desde n8n 2.36.0 permiten configurar qué hacer con una ejecución perdida, siempre que utilicen el planificador duradero; desde 2.45.0, este es el modo predeterminado si no se deshabilitó. La opción predeterminada indicada por n8n es descartar las ejecuciones perdidas y reanudar el calendario. Las otras opciones recuperan una ejecución reciente, no reproducen necesariamente todo el atraso (política de ejecuciones perdidas; opciones del nodo). Comprueba la versión del nodo antes de esperar ese menú.

Registra la regla que esperas, no solo el resultado

Para que otra persona pueda revisar una incidencia, deja una ficha breve: nombre del flujo; versión de n8n; tipo de instalación; zona del flujo o indicación de que hereda la de la instancia; zona de la instancia; regla exacta; momento en que se guardó y publicó; fecha y zona de la próxima ejecución esperada; y marca temporal de la ejecución observada. No incluyas credenciales ni datos privados en una captura compartida.

Con ese registro se pueden separar tres preguntas distintas: qué horario se quiso configurar, qué horario interpreta n8n en esa versión y cuándo se ejecutó realmente. Solo después de compararlas tiene sentido atribuir una diferencia al cambio de hora, a un intervalo contado desde la publicación, a una expresión Cron o a una parada de la instancia. La documentación de Schedule Trigger y del planificador duradero ofrecen el punto de partida técnico; el registro de tu propia instancia aporta el hecho que falta para resolver tu caso.

Fuentes y agradecimientos

• Documentación de n8n sobre Schedule Trigger: prioridades de zona, tipos de reglas, requisito de publicación y opciones del nodo.
• Ajustes de los flujos de n8n: ubicación del ajuste de zona horaria.
• Zona horaria en instalaciones autogestionadas y zona de n8n Cloud: configuración de la instancia.
• Planificador duradero de n8n y problemas habituales del disparador: diferencias por versión, intervalos, Cron y ejecuciones perdidas.

Gracias al equipo de documentación de n8n por publicar estas referencias y mantener visibles sus límites y cambios por versión. Esta guía interpreta sus documentos públicos; n8n no ha revisado ni avalado este artículo.