n8n Schedule Trigger: mastering cron expressions and timezones

An email digest that fires at 3am instead of 8am, a weekly SEO report that goes out on Monday instead of Friday, a reminder for an incomplete case file that never fires because the instance was mid-restart: most Schedule Trigger incidents in n8n don't come from a visible configuration mistake, but from an implicit assumption about timezone or trigger reliability. Yet this node sits at the core of several FlowKit workflows — the daily digest in the Inbox AI Pack, the reminders in the Compliance & Audit Pack, the nightly sync in the RAG Assistant Pack — which is reason enough to understand it in detail before shipping it to production.

The two modes of the Schedule Trigger

The node offers two ways to define a cadence, grouped under a single "Trigger Rule" (and you can add several to the same node — more on that below):

• Interval — guided fields: Seconds, Minutes, Hours, Days, Weeks, or Months, with sub-fields like "Trigger at Hour" and "Trigger at Minute." This is the recommended mode for 90% of cases: a daily digest at 8am, a sync every 15 minutes, a report every Monday at 7am.
• Cron Expression — a classic cron string with five fields (minute, hour, day of month, month, day of week), plus an optional sixth field prepended for seconds. Reach for this mode as soon as the need goes beyond what the guided UI can express: 0 8 1-7 * 1 for "the first Monday of every month," or */10 8-18 * * 1-5 for "every 10 minutes, 8am to 6pm, Monday to Friday."

To build or double-check a cron expression without mistakes, a tool like crontab.guru (not affiliated with n8n) remains the fastest sanity check before pasting the expression into the field.

Cron expressions you can copy-paste

Schedule you want	Cron expression
Every day at 8:00	0 8 * * *
Every 15 minutes	*/15 * * * *
Every Monday at 7:00	0 7 * * 1
Weekdays at 9:30	30 9 * * 1-5
Every 10 min, 8am–6pm, Mon–Fri	*/10 8-18 * * 1-5
First day of the month at 6:00	0 6 1 * *
First Monday of the month at 8:00	0 8 1-7 * 1
Every hour on the half-hour	30 * * * *
Twice a day (8:00 and 19:00)	0 8,19 * * *
Every 30 seconds (6-field syntax)	*/30 * * * * *

Paste any of these into the Cron Expression field of a Trigger Rule — and remember the times fire in the workflow's timezone, which is exactly what the next section is about.

Multiple rules in a single node

A common trap is duplicating an entire workflow just to handle two different cadences — for instance, an hourly digest on weekdays and a single one on Saturday morning. The Schedule Trigger accepts multiple Trigger Rules on the same node: each can independently use Interval or Cron Expression mode, and the workflow fires as soon as any one of them activates. That keeps a single workflow to maintain instead of two copies that eventually drift apart.

Timezones: the most common trap

This is the number-one source of error with this node, precisely because it doesn't produce a visible error — the workflow still fires, just at the wrong time. Timezone resolution follows a precise order:

1. The workflow's timezone, set in the workflow's settings (three-dot menu → Settings → Timezone). It takes priority over everything else once defined.
2. The instance's timezone, controlled by the GENERIC_TIMEZONE environment variable on self-hosted instances. Without that variable, n8n falls back to America/New_York — a timezone that shifts a digest meant to fire at 8am by 5 to 6 hours for a France-based team.
3. On n8n Cloud, the timezone is auto-detected when the account is created; failing that, it falls back to GMT.

The safe practice is to never rely on the default behavior: set GENERIC_TIMEZONE=Europe/Paris (or the relevant timezone) at the self-hosted instance level, and explicitly set the timezone in the settings of every business-critical workflow. Using a full IANA timezone name (Europe/Paris, not CET or a raw offset) removes any ambiguity around daylight saving transitions, which the system handles automatically once the correct named timezone is set.

Real-world use cases across the FlowKit packs

• Daily digest (Inbox AI Pack): a Schedule Trigger in Interval mode fires each morning to send yesterday's email summary to Slack or Telegram. A timezone mismatch here means the digest lands in the middle of the night or mid-afternoon instead of when the team logs on.
• Incomplete case file reminders (Compliance & Audit Pack, covered in detail in our article on automating follow-ups for incomplete files): here the cadence — often daily or weekly — has a direct impact on regulatory deadlines, which makes trigger reliability especially sensitive.
• Weekly SEO report (see our guide on automating Search Console reports): a Cron Expression like 0 7 * * 1 sends the report every Monday at 7am, ahead of the weekly team meeting.
• Nightly Notion → Supabase sync (RAG Assistant Pack): a scheduled trigger during off-peak hours avoids re-indexing the vector store while the team is actively querying it.

What happens if the instance is offline when the run was due?

A missed scheduled trigger stays missed: n8n does not automatically catch up on a run whose time has passed while the instance was unavailable (restart, outage, upgrade). This isn't an n8n-specific gap but a general trait of single-machine cron-style systems — it's exactly the problem examined in a Google study published in Communications of the ACM (Davidovič & Guliani, 2015 — Google Scholar): on a classic cron, the failure domain is limited to a single machine, and if that machine is down, neither the scheduler nor the jobs it was meant to launch run at all — which is exactly why Google built a distributed cron service for its own internal needs.

For a self-hosted n8n instance, the practical takeaway is twofold:

• Uptime monitoring of the instance itself (not just execution monitoring) is essential once a scheduled workflow carries real business weight — see our reliability checklist in the self-hosted vs cloud guide.
• An Error Workflow catches execution failures, but not triggers that never fired because the instance was unavailable — the two problems need separate handling.
• If the volume of scheduled triggers grows on an instance already running in queue mode with Redis, remember it's the main instance, not the workers, that's responsible for firing crons on time.

Best practices to keep in mind

• Always set the timezone explicitly — at the instance level (GENERIC_TIMEZONE) and for every business-critical workflow, using a full IANA name.
• Prefer Interval when it's enough: more readable for a teammate picking up the workflow later than a cron expression they have to decode.
• Group cadences with multiple Trigger Rules rather than duplicating entire workflows.
• Space out frequent triggers to stay under the rate limits of any downstream AI APIs — see our article on 429 errors and pacing AI calls.
• Test the workflow manually ("Execute workflow" button) before activating the Schedule Trigger in production, to validate the logic independently of trigger timing.

Configured correctly, the Schedule Trigger becomes invisible — the digest arrives on time, the reminder goes out on the right day, the report lands before the meeting. It's a five-minute configuration detail that saves weeks of confusion over "why didn't this workflow fire when it should have." The scheduled workflows in the Inbox AI (€79), RAG Assistant (€119), and Compliance & Audit (€149) packs ship with their Schedule Trigger already configured — all that's left is adjusting the timezone to your team.