n8n Schedule Trigger: time zone, cron, and why it won't fire

n8n's Schedule Trigger node starts a workflow at fixed intervals (every N seconds, minutes, hours, days, weeks, or months) or on a custom cron expression. It fires in the workflow's time zone, falling back to the instance's, and only after the workflow is saved and published.

n8n behavior below is quoted from n8n's Schedule Trigger docs and its common issues page, read 2026-09-28. The last section adds Sume's Create a run rules for the case where the scheduled step starts a paid video job.

How do I set up the Schedule Trigger?

Add a Trigger Rule and pick a Trigger Interval: Seconds, Minutes, Hours, Days, Weeks, Months, or Custom (Cron). Each interval asks for its own fields, such as Trigger at Hour and Trigger at Minute for Days. You can add several rules to run one workflow on different schedules.

The Custom (Cron) interval takes five fields, or six with an optional seconds field in front. n8n's own examples: 0 6 * * * is 6:00 AM every day, 0 9 * * 1-5 is 9:00 AM Monday through Friday, and */10 * * * * * is every 10 seconds. The field order is covered in cron expressions: 5 vs 6 fields.

Which time zone does the Schedule Trigger use?

The workflow's time zone if you set one, otherwise the instance's. The instance default is America/New York on self-hosted n8n; n8n Cloud tries to detect the owner's time zone at sign-up and falls back to GMT.

• One workflow: open it, select the three dots, then Settings, change Timezone, and save.
• The whole instance: on self-hosted n8n, set the GENERIC_TIMEZONE environment variable; on n8n Cloud, admins change it in the Admin dashboard.
• Dates in expressions follow the same setting: n8n's Luxon helpers, including $today, use the n8n time zone. Plain JavaScript Date() does not respect the workflow time zone.
• The Wait node's time-based waits are the exception: they always use the n8n server's time, whatever the time zone setting.

Why is my n8n Schedule Trigger not working?

Several of n8n's documented causes come from how publishing works: the schedule is read when you publish, not when you edit.

How do I start a paid job on a schedule without running it twice?

Derive an idempotency key from the date the run is for, not from the moment it fires. With Sume, an HTTP Request node posts to your Format's runs endpoint with a Bearer credential (n8n's Bearer auth is header auth with Name Authorization) and this header:

• Same key, same body: Sume answers 200 with the original run, with no second run and no second charge.
• Same key, different body: 409 idempotency_conflict, and nothing runs. In current code the body includes communication.webhook_url, and a Wait node's resume URL is unique to each execution, so a second execution on the same day gets this 409. Treat it as "already started today".
• Keys are scoped to one Format, and a key is up to 255 characters.
• Set generation_spend_cap_usd on the body so one run cannot spend past your ceiling (up to $500).

Idempotency-Key: daily-short-{{ $today.format('yyyy-LL-dd') }}

Should the schedule live in n8n or in Sume?

Keep it in n8n when the workflow does more than start the video, such as posting it or notifying someone; pausing for the result is covered in resume an n8n Wait node on a Sume webhook. If the schedule only starts an agent task, Sume's own schedules take a 5-field cron expression and an IANA time zone in the dashboard; see scheduled AI video agent runs.