The n8n Schedule Trigger:
cron, intervals, and the timezone trap.

My morning email digest fired at 3am for a week before I caught it. The workflow timezone was set to UTC. My schedule said 8am. The server thought 8am UTC meant 3am Eastern and nobody disagreed with it. The Schedule Trigger is simple until the timezone eats you. Here's everything that can go wrong and how to stop it.

What the Schedule Trigger actually does (and why you shouldn't overuse it)

Most n8n workflows start because something external happened: a webhook fires, someone submits a form, a new row appears in a Google Sheet. The Schedule Trigger node is different. It starts a workflow because enough time has passed. That's it. No external dependency, no waiting for someone to do something. Just a clock.

This makes it the right starting node for anything that should run regularly on its own: a morning briefing, a daily backup, a price check every hour, a report that goes out on the first of the month. If the workflow's trigger condition is "it's time," you want a Schedule Trigger.

What it does NOT do: it doesn't fire for missed executions. If your n8n instance is down when a scheduled run was supposed to happen, that run is gone. n8n will pick up the next scheduled time once it comes back online, but it won't try to backfill what it missed. This matters a lot in practice. I'll come back to it.

The node itself is simple. You configure it, activate the workflow, and n8n's internal scheduler takes over. Each time the configured schedule fires, a new workflow execution starts at that node and continues downstream from there. The Schedule Trigger passes minimal data (just a timestamp and some execution metadata), so the real work usually starts with the next node fetching whatever you actually need.

Interval mode vs. cron: pick the right one or pay the price

The Schedule Trigger gives you two ways to define when it fires. The choice between them isn't complicated once you understand what each one is actually for.

Interval mode

Interval mode fires the workflow every X units of time: every 15 minutes, every 2 hours, every 7 days. You pick a number and a unit (minutes, hours, or days) and n8n handles the rest.

This is the right mode when you literally just want "run this every N minutes" and you don't care about the clock time. If your workflow checks an external API for new records and the check doesn't need to happen at any specific time of day, interval mode is simpler and good enough. No cron syntax to think about, no edge cases around month lengths or day-of-week math.

One important thing to know: interval mode counts from when the workflow was last activated or last executed. It's relative, not anchored to the clock. If you activate a workflow with a 1-hour interval at 2:47pm, it runs at 3:47pm, then 4:47pm, and so on. If it was down for 3 hours and just came back, it fires once and then resumes the interval from there. Not from the missed slots.

Cron expressions

Cron mode lets you describe a schedule using a cron expression: a string of 5 or 6 fields that defines exactly when something should run. The format n8n uses is standard Unix cron:

# minute  hour  day-of-month  month  day-of-week
#  (0-59) (0-23)    (1-31)    (1-12)    (0-7)
#
# * = any value
# , = list of values (0,15,30,45 = every quarter hour)
# - = range (1-5 = Monday through Friday)
# / = step (*/4 = every 4 units)

Cron is the right choice when timing matters: run at 8am, run on weekdays only, run on the first of the month. It gives you precision that interval mode can't.

Use interval mode for: API polling, queue drains, any "check frequently" task where clock time is irrelevant.
Use cron for: morning reports, weekly digests, anything that should happen at a meaningful time, anything that has a day-of-week or calendar dependency.

Copy-paste cron expressions for common schedules

These are the ones I actually use or have used. All times assume UTC. Subtract your local offset if you need them to fire at a local time (more on that in the timezone section).

Not sure if your cron expression is right? Paste it into crontab.guru and it'll tell you in plain English exactly when it fires.

Real examples from my stack

Here's what the Schedule Trigger is actually doing in my workflows right now. Not hypotheticals. These are live.

Email triage bot: weekdays at 8am ET

Every weekday morning, a workflow wakes up and scans my inbox for anything that landed overnight. It categorizes messages by priority, extracts action items, and dumps a summary into a Notion database so I have a clean picture of what needs attention before I do anything else. The cron for this one is 0 12 * * 1-5 (noon UTC, which is 8am Eastern). If I ran it in UTC-naive interval mode set to "every 24 hours," it might drift and eventually fire in the middle of the night.

The cron locking it to a weekday morning was a deliberate choice. There's no value in triaging email at 3am on a Sunday. The schedule is part of the workflow's design, not an afterthought.

Traffic monitor: every 4 hours via GoatCounter

This workflow hits the GoatCounter API every 4 hours, pulls the top pages and referrer breakdown for the last 24 hours, and writes the numbers into a log. I use 0 */4 * * *. Nothing fancy. It just runs on the interval because traffic monitoring doesn't have a "right time." Spread out the checks and you get a picture of traffic across the day. If I ran this on a daily cron at midnight, I'd be looking at 24 hours of data in one shot with no granularity.

Four hours is the sweet spot for the GoatCounter API limits I'm working with. Running hourly would burn through the rate limit during any spike. Running every 6 hours misses some of the intraday patterns I care about.

Crypto price check: specific cron for market hours

The crypto workflow runs on a more specific schedule: 0 */2 * * * during market-adjacent hours, which I've tuned based on when price movement actually matters to the signals I'm watching. This is where cron earns its keep over a simple interval. I can say "check at these specific hours" instead of "check every 2 hours from whenever the workflow was activated." The anchoring matters when you're looking at whether a price crossed a threshold during a specific window.

Weekly self-report: Monday 9am UTC

Every Monday morning, a workflow aggregates the previous week's metrics (traffic, revenue signals, email stats, experiment outcomes) and posts a summary to a Slack channel. The schedule is 0 9 * * 1. It fires once a week, at a time that puts the summary in front of me when the week is starting. This one would break completely if I used interval mode. "Every 168 hours" sounds equivalent, but it's not anchored to Monday morning. It'd drift to Wednesday night within a few weeks if I ever restarted n8n.

The timezone problem

This is the thing that gets people. n8n's Schedule Trigger uses UTC by default. If you're running n8n on a self-hosted instance, the timezone your server runs in might not match UTC, which adds another layer of confusion. Here's the rule I follow: always write your cron expressions in UTC, always convert deliberately.

If I want a workflow to run at 8am Eastern Time, I know that Eastern is UTC-4 in summer (EDT) or UTC-5 in winter (EST). So my morning cron runs at 0 12 * * * in summer and I update it to 0 13 * * * when the clocks change. Yes, manually. It's annoying but it's one edit twice a year and it keeps the behavior predictable.

The alternative is to let n8n use the server's local timezone, which works fine if your server and your expectations are aligned. But I've been burned by cloud instances where the system timezone was set to UTC regardless of where I was. Suddenly my "8am" workflow was firing at 4am local time. UTC-explicit is just safer.

How to figure out the UTC equivalent of any local time:

# Eastern  → UTC-5 (EST) / UTC-4 (EDT)
# Central  → UTC-6 (CST) / UTC-5 (CDT)
# Mountain → UTC-7 (MST) / UTC-6 (MDT)
# Pacific  → UTC-8 (PST) / UTC-7 (PDT)
#
# 8am Eastern  = noon UTC (summer) / 1pm UTC (winter)
# 9am Eastern  = 1pm UTC (summer) / 2pm UTC (winter)
# 6pm Eastern  = 10pm UTC (summer) / 11pm UTC (winter)

n8n does have a timezone setting in the environment variables: GENERIC_TIMEZONE. If you set that to your actual timezone (e.g., America/New_York), n8n will interpret cron expressions in that timezone. This is probably the cleaner solution if you're self-hosting and want to set it once and forget it. The tradeoff: if you ever move the instance or change the config, your cron expressions are suddenly wrong in a non-obvious way. UTC-explicit means the cron expressions are self-documenting.

Mistakes I've seen (and made)

Running things too frequently. Every 5 minutes sounds reasonable until you realize it generates 288 workflow executions per day, every API you call 288 times, and your rate limits are gone by mid-morning. Most things don't need to run every 5 minutes. I audit my intervals every few months and almost always find one where I can cut the frequency in half with zero practical impact.

Assuming the workflow will fire on time if n8n is down. It won't. The Schedule Trigger fires when n8n is running and the time has passed. If the instance restarts at 8:05am and a workflow was scheduled for 8:00am, that execution is just gone. For things where missing a scheduled run genuinely matters (daily backups, time-sensitive reports), you either need to make n8n's uptime a real priority or build a mechanism to detect the gap on the next run.

Using interval mode when you actually need clock-anchored timing. "Every 24 hours" and "daily at 8am" sound the same but they're not. Interval mode is relative to when the workflow last ran. If the workflow ever restarts (you updated it, n8n had a hiccup, the server rebooted), the 24-hour interval resets. After a few months, your "morning" workflow is firing at 11pm. Use cron when the clock time is part of the intent.

Putting expensive operations in a high-frequency schedule without any guards. I've seen workflows that hit the OpenAI API every 10 minutes to summarize something that doesn't change that often. The schedule trigger doesn't know your API costs are mounting. It just fires. Add a check early in the workflow: has the input actually changed since the last run? If not, stop early. This saved me an embarrassing amount on API spend once I started treating it as a default pattern.

Not checking that the workflow is actually active. The Schedule Trigger only fires when the workflow is activated. If you're building and testing in the editor, you might have noticed that running a workflow manually from the editor doesn't use the schedule. It just executes once immediately. That's fine for testing. But "I ran it manually and it worked" doesn't tell you whether the scheduled version is set up correctly. Always check the workflow's activation toggle before assuming it'll fire on its own.

Forgetting that the Schedule Trigger output is minimal. When a schedule fires, the trigger node outputs something like {"timestamp": "2026-03-21T12:00:00.000Z", "executionMode": "schedule"}. That's it. Whatever data your workflow needs to do its actual job (the emails to process, the prices to check, the traffic numbers to pull) has to come from the next node. A common beginner pattern is to wire the Schedule Trigger directly into a node that expects some specific input, and then wonder why it's not finding anything. The trigger just starts the workflow. Everything else you have to fetch.

One more thing: the workflow has to be saved and active

This sounds obvious until it bites you. The schedule only runs when the workflow is both saved and active. The toggle is in the top right of the editor. Orange dot = active, grey = inactive. I've spent time debugging a schedule that "wasn't firing" before realizing I had a second copy of the workflow that was active and this one wasn't. Check the dot before blaming the cron.

What's next

The Schedule Trigger is just the starting node. The interesting stuff is everything that comes after it: the API calls, the data transforms, the conditional logic that decides whether to send the message or skip it. A cron expression that fires reliably is table stakes. What makes a scheduled workflow actually valuable is what it does with the execution time.

The workflows in my stack that run on the Schedule Trigger aren't just "run a thing on a timer." They're checking whether conditions are met, comparing against previous runs, making decisions based on what they find, and routing to different branches depending on the outcome. The schedule is just the clock. The rest is the automation.

If you'd rather start from a working stack than build each piece from scratch, I put together a set of production n8n workflows that I actually use, including ones that run on schedules. The email triage workflow, the traffic monitor, the weekly self-report. Each one comes with full documentation explaining what every node does and why the schedule is set up the way it is. You can drop them into your own n8n instance and have real timed automation running in under an hour.

Set the timezone explicitly. Double-check it against UTC math before you walk away. Scheduled workflows fail silently, which means you don't know they're wrong until you need them and they weren't there. Get the clock right first. Everything else is configurable later. The See Database Suite MCP → covers the full self-hosted setup if you want to see the infrastructure behind the schedules.