Horarios en n8n: revisa tus tareas tras el cambio de hora

Si un informe de n8n aparece una hora antes después del cambio de hora, conviene revisar qué significa su horario antes de modificarlo. «Todos los días a las 09:30 en Madrid» y «cada 24 horas» son requisitos distintos. Corregir el reloj equivocado puede desplazar otras tareas o provocar un segundo envío.

El horario de verano de 2026 terminó el 25 de octubre: a las 03:00 de la hora peninsular se volvió a las 02:00, según la orden publicada en el BOE. Esta revisión sirve también para cualquier automatización que atienda a personas en zonas horarias diferentes.

1. Define la hora que necesita el negocio

Escribe una regla que otra persona pueda comprobar: «Enviar un único resumen de oportunidades a las 09:30 de Europe/Madrid, de lunes a viernes». Añade el destinatario, la fecha de los datos y qué hacer si el servicio estaba detenido. Los festivos requieren una regla adicional; una programación de lunes a viernes no equivale por sí sola al calendario laboral de la empresa.

Para un informe pensado para Canarias, acuerda si debe llegar a las 09:30 de allí o al mismo instante que el informe peninsular. Tampoco confundas un cierre diario con una tarea que necesita dejar transcurrir exactamente 24 horas desde la ejecución anterior: durante un cambio de hora, ambas condiciones pueden dejar de coincidir.

Ejemplo hipotético: una programación fija en UTC

Un negocio programa un resumen a las 07:30 UTC. El 24 de octubre de 2026 eso corresponde a las 09:30 en Madrid; el 26 de octubre corresponde a las 08:30. Si el compromiso comercial sigue siendo las 09:30 de Madrid, la referencia de invierno es las 08:30 UTC. Este cálculo explica el desplazamiento, pero no demuestra que ese sea el fallo de tu instalación.

2. Comprueba la zona horaria del flujo

La documentación de Schedule Trigger indica que se utiliza la zona del flujo y, si no está definida, la de la instancia. Para programar, hay que guardar y publicar el flujo.

Abre los ajustes del workflow y revisa el campo Timezone. Para una tarea ligada al horario de Madrid, selecciona Europe/Madrid. Comprueba también la configuración horaria que heredaba antes, para entender la causa del desfase.

Limita el cambio al flujo afectado cuando esa sea la necesidad. Cambiar la zona general de la instancia puede alterar otros procesos que dependan de ella. Anota el valor anterior, la regla acordada y quién validará la siguiente ejecución.

Revisa la regla completa, no solo la cifra de la hora

Comprueba los días incluidos, las reglas adicionales del disparador y si existe otro flujo que haga el mismo envío. Ajusta la programación diaria a la hora local acordada y confirma que la versión modificada queda publicada conforme a la interfaz de tu versión de n8n. Una ejecución manual sirve para probar el recorrido del trabajo, pero no acredita que el próximo disparo automático vaya a ocurrir a la hora prevista.

3. Distingue el disparo, los datos y la entrega

Compara tres momentos: cuándo debía empezar la tarea, cuándo comenzó realmente y cuándo el sistema de destino aceptó o entregó el resultado. Si n8n arrancó a las 09:30 y el correo llegó a las 09:42, investiga la duración del proceso, la cola o el proveedor antes de cambiar el horario.

Conserva la zona o el desplazamiento horario al intercambiar fechas y horas. Una marca terminada en Z expresa UTC; una hora sin zona necesita un acuerdo explícito entre sistemas. Si el ERP entrega una fecha de negocio como «2026-10-26», no la conviertas automáticamente en un instante a medianoche y después a otra zona: podrías terminar seleccionando datos del día anterior.

En el informe, muestra el periodo que realmente se consultó. Así podrás distinguir un envío realizado a la hora correcta con datos incorrectos de un problema del disparador.

4. Prueba el cambio sin repetir operaciones reales

En un entorno de prueba, utiliza fechas representativas de antes y después del cambio de hora. Comprueba la conversión esperada y una ejecución programada con un destinatario de prueba. No cambies el reloj del servidor de producción para simular el cambio estacional.

Si la tarea se ejecuta de madrugada, define qué debe pasar cuando su hora local no exista o se repita durante la transición. Verifica el comportamiento del planificador y la versión instalada; no presupongas que todos los disparadores recuperan las tareas perdidas de la misma manera. Si el negocio lo permite, elegir una hora fuera de esa franja simplifica la operación.

Antes de recuperar un envío aparentemente perdido

Busca primero el resultado en el sistema de destino y comprueba si otra ejecución sigue en curso. Para un resumen diario, identifica la operación por cliente, tipo de informe y fecha local de negocio. Un control que registre de forma consistente esa operación ayuda a impedir que dos ejecuciones envíen el mismo resumen; cambiar el horario por sí solo no proporciona esa protección.

Da la revisión por terminada cuando la ejecución automática entregue una sola vez el periodo correcto al destinatario previsto y deje un registro comprensible. Si falla, el responsable debe recibir una alerta útil, como explicamos en la guía de errores, alertas y reintentos en n8n.

Un horario documentado es más fácil de mantener

Guarda junto al flujo la zona horaria, los días de ejecución, el periodo de datos, la política ante retrasos y la persona responsable. Revisa ese acuerdo cuando cambies de servidor, de destinatarios o de versión.

En Serboweb podemos revisar la programación y el seguimiento de tus automatizaciones con n8n administrado. El punto de partida es concreto: qué tarea debe realizarse, a qué hora local y qué evidencia confirma que se ha completado una sola vez.