Configurar correctamente el Cron y el Schedule Trigger en n8n: la zona horaria casi siempre tiene la culpa

La expresión cron en el Schedule Trigger casi siempre es correcta. Lo que en la práctica casi nunca es correcto es la zona horaria en la que n8n evalúa esta expresión. Exactamente este patrón se repite en tres hilos reales del foro de n8n, que analizamos en detalle en este artículo: un equipo en modo Queue, un usuario en Brasil y un usuario en Londres que se sorprendió por una diferencia de una hora aunque la configuración de su workflow estaba en GMT. En los tres casos, la expresión cron en sí era correcta, la causa estaba un nivel más abajo.

Según la documentación oficial del Schedule Trigger el nodo utiliza una jerarquía de zonas horarias con varios niveles, y es exactamente ahí donde surgen la mayoría de las sorpresas. Si entiendes cómo n8n resuelve estos niveles, puedes evitar casi todos los errores de zona horaria antes de que lleguen a producción. Estado: julio de 2026.

Cómo interpreta el Schedule Trigger las expresiones cron

En modo personalizado, el Schedule Trigger acepta, según la documentación, una expresión cron clásica de seis campos, donde el sexto campo, opcional, representa los segundos, seguido de minuto, hora, día del mes, mes y día de la semana. La documentación incluye una tabla de referencia con patrones habituales:

• Cada X segundos: `*/10 * * * * *`
• Cada X minutos: `*/5 * * * *`
• Cada hora: `0 * * * *`
• Diariamente: `0 6 * * *`
• Semanalmente: `0 12 * * 1`
• Mensualmente: `0 0 1 * *`

Para hacer pruebas, el propio n8n recomienda verificar antes una expresión en crontab.guru, aunque sin la columna opcional de segundos, porque esa herramienta solo conoce cinco campos. Este paso ayuda por sí solo a descartar errores de sintaxis antes de entrar siquiera en las trampas de la zona horaria. La expresión en sí es intrascendente en casi todos los problemas discutidos públicamente, el problema empieza después, con la pregunta de en qué zona horaria evalúa n8n realmente esa expresión.

La jerarquía de zonas horarias: instancia, workflow y worker

n8n establece un orden de prioridad claro para la zona horaria. Si en el propio workflow hay una zona horaria configurada, esa es la que se aplica. Si falta, n8n recurre a la zona horaria de la instancia. En instancias autoalojadas, el valor por defecto no es UTC ni la zona horaria de tu servidor, sino, según la documentación, `America/New_York`. En n8n Cloud, el sistema intenta detectar automáticamente la zona horaria del titular de la cuenta, pero recurre a GMT si la detección falla.

La página sobre problemas comunes del Schedule Trigger describe exactamente este mecanismo como la fuente de errores más frecuente y menciona dos puntos de ajuste: a nivel de workflow, la zona horaria se puede ajustar mediante los tres puntos arriba a la derecha en el canvas, luego Settings y el parámetro Timezone. De forma global, para toda la instancia, en instalaciones autoalojadas se configura en su lugar la variable de entorno `GENERIC_TIMEZONE`. Importante: esta variable afecta a la instancia, no automáticamente a cada proceso individual que pertenece a esa instancia, como muestra el primer caso a continuación.

Tres casos reales del foro de n8n

Caso 1: modo Queue, configurado correctamente, pero aun así incorrecto

En el hilo "Schedule Trigger executing at wrong time" un usuario describe un disparador semanal que debía ejecutarse los domingos a las 3 de la madrugada PST, pero en realidad se disparaba a las 19 horas. Tanto la configuración del workflow como la zona horaria de la instalación estaban correctamente en PST, un antiguo nodo Cron incluso funcionaba en paralelo sin errores. El usuario encontró la solución por sí mismo: "We use n8n in queue mode - and it turns out, I forgot to set the timezone parameters on the workers!!!" La instancia principal tenía la zona horaria correcta, pero los pods worker separados en Kubernetes no. Tras configurar la variable de entorno TZ en los despliegues worker, el workflow de prueba se ejecutó "on the dot", como confirmó el usuario. Quien opere n8n en modo Queue debe configurar la zona horaria en cada componente individual, no solo en la instancia principal.

Caso 2: Brasil y el valor por defecto silencioso

En el hilo "Schedule Trigger - what's the time zone?" un usuario de Brasil (UTC-3) reporta una diferencia de exactamente dos horas: un disparador programado para las 11 horas se ejecutó a las 13 horas en su lugar. La causa era simplemente el valor por defecto no sobrescrito `America/New_York`, que n8n aplica a las instancias autoalojadas cuando nadie configura explícitamente otra cosa. Como solución se mencionaron dos vías, cambiar la zona horaria directamente en el workflow mediante Settings, o configurarla globalmente mediante `GENERIC_TIMEZONE` en el archivo Docker Compose o en la imagen Docker. Quien configure una instalación nueva de n8n debería tener en cuenta esta variable desde el principio, en lugar de añadirla solo después del primer disparo erróneo.

Caso 3: Londres, el horario de verano y el malentendido en torno a GMT

En el hilo "Schedule Trigger and Confusion Over Time Zone Settings" el usuario kpakfar se sorprendió por una diferencia de una hora entre `DateTime.now()`, que mostraba correctamente la hora de Londres incluyendo el horario de verano, y el Schedule Trigger, que aparentemente funcionaba según la configuración denominada GMT. El miembro de la comunidad ihortom aclaró que el disparador funcionaba correctamente según la hora de Londres, no según la denominación literal "GMT 00:00". La indicación al respecto: quien realmente quiera una zona horaria fija sin cambio de horario de verano debe seleccionar explícitamente "(GMT+00:00) GMT (no daylight saving)". La opción de zona horaria normal, vinculada a una ciudad, tiene en cuenta el horario de verano automáticamente, aunque su etiqueta no lo revele a primera vista. Quien necesite horas UTC fijas independientes del horario de verano, por ejemplo para sistemas que hablan UTC en sí mismos, debería elegir específicamente la variante sin horario de verano en lugar de una zona horaria basada en ciudad.

Cómo configurar la zona horaria de forma fiable

• Comprobar la expresión cron por separado: Prueba primero la sintaxis pura en crontab.guru, sin el campo opcional de segundos, antes de ocuparte de la zona horaria.
• Configurar explícitamente la zona horaria del workflow: No confíes en el valor por defecto de la instancia, sino introduce la zona horaria en la configuración del workflow, especialmente con varios workflows para distintos públicos o países.
• Configurar `GENERIC_TIMEZONE` en autoalojamiento: Sin esta variable, tu instancia se queda en `America/New_York`, independientemente de dónde funcione realmente tu servidor.
• Modo Queue: no olvides los workers: Configura la zona horaria en cada despliegue worker individualmente, una instancia principal correctamente configurada no es suficiente por sí sola.
• Decidir conscientemente sobre el horario de verano: Elige una zona horaria basada en ciudad si el horario de verano debe aplicarse automáticamente, o una variante fija sin horario de verano si necesitas una hora UTC exacta independiente de la estación.

En NordFlux configuramos los workflows de n8n de modo que los disparadores cron se ejecuten desde el principio en la zona horaria correcta, ya sea en una única instancia o en modo Queue con varios workers. Así tus automatizaciones sensibles al tiempo se mantienen fiables, y conservas el control sobre cuándo se activan realmente tus trabajadores digitales. Más información sobre nuestro enfoque la encuentras en automatización de n8n de NordFlux.

Preguntas frecuentes

¿Por qué mi disparador cron se ejecuta a la hora equivocada aunque la expresión sea correcta?

En la gran mayoría de los casos, no es la expresión cron en sí, sino la zona horaria en la que n8n la evalúa. Comprueba primero la configuración del workflow, luego la zona horaria de la instancia, y en modo Queue además la zona horaria de cada worker.

¿Cuál es la zona horaria por defecto de n8n si no configuro nada?

En instancias autoalojadas, el valor por defecto según la documentación es `America/New_York`. En n8n Cloud, el sistema intenta detectar automáticamente la zona horaria, y recurre a GMT si la detección falla. Ambos valores por defecto rara vez coinciden por casualidad con tu zona horaria real.

¿Cómo configuro la zona horaria para un solo workflow?

Abre el workflow en el canvas, haz clic en los tres puntos arriba a la derecha, elige Settings y ajusta el parámetro Timezone. Esta configuración sobrescribe la zona horaria de la instancia solo para este workflow.

¿Debo tener en cuenta algo adicional en modo Queue?

Sí. La configuración de zona horaria de la instancia principal no basta en modo Queue, porque los disparadores se ejecutan en procesos worker separados. Configura la variable de entorno TZ adecuada en cada despliegue worker, de lo contrario la instancia principal puede estar correctamente configurada y el disparador puede activarse igualmente a la hora equivocada.

¿Cómo evito sorpresas por el horario de verano?

Una zona horaria basada en ciudad como Londres o Berlín se adapta automáticamente al horario de verano y al horario estándar. Si en cambio quieres una hora fija independiente de la estación, elige explícitamente una opción de zona horaria sin horario de verano, en lugar de fiarte solo de la etiqueta.