La expresión cron casi siempre es correcta, la zona horaria no. Tres casos reales del foro de n8n muestran por qué los Schedule Triggers se disparan a la hora equivocada.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
NordFlux crea empleados digitales para las organizaciones: automatizaciones y agentes KI que asumen el trabajo repetitivo. Usted mantiene el control.
Resumen de todos los tipos de trigger de n8n: Schedule, Webhook, Polling, Manual y Chat, incluyendo recomendación de uso para cada escenario.
Reconoces las stuck executions en n8n por indicadores de estado que no avanzan. Así configuras correctamente EXECUTIONS_TIMEOUT y encuentras la causa.
De forma predeterminada, n8n se ejecuta en America/New_York en lugar de Europe/Berlin. Así se configura correctamente GENERIC_TIMEZONE y la zona horaria del workflow.
Instancia, workflow y worker pueden tener cada uno su propia zona horaria, y es precisamente esa interacción la que provoca los típicos errores de Cron. NordFlux se encarga de la operación gestionada de su instancia n8n y garantiza que los workflows programados se ejecuten de forma fiable a la hora correcta. En la primera conversación revisamos su configuración de triggers en detalle.
