How to Schedule Workflows in n8n (Cron Guide)
This page may contain affiliate links. If you buy through them we may earn a commission at no extra cost to you.
Direct answer: scheduling a workflow in n8n means adding a Schedule Trigger node as the workflow's starting point, choosing either a simple interval (every N minutes, hours, or days) or a cron expression for anything more specific, confirming the timezone is set correctly, and then switching the workflow to Active. That last step is the one people miss: a scheduled workflow sitting inactive in the editor will never run on its own, however correctly the trigger itself is configured. The whole setup takes under five minutes; getting the timezone and activation right the first time is what actually saves the debugging later.
Step 1: Add the Schedule Trigger node
Start a new workflow and add a Schedule Trigger node as the trigger. This replaced n8n's older Cron node a while back and does the same job with a friendlier interface: a simple mode for common intervals, and a cron-expression mode for anything the presets don't cover. If you're editing an existing workflow that still uses the legacy Cron node, it still runs, but there's no reason to build new workflows on it now that Schedule Trigger covers the same ground more clearly.
Step 2: Choose an interval or write a cron expression
For straightforward cases, every 15 minutes, once a day at a set time, every Monday, the Schedule Trigger's interval presets handle it without touching cron syntax at all. For anything irregular, every weekday at 9 AM and 5 PM, the first of the month, every six hours starting at 2 AM, switch to the node's cron expression field. A standard five-field cron expression (minute hour day month weekday) covers nearly everything; 0 9 * * 1-5 runs at 9 AM on weekdays, and */15 * * * * runs every 15 minutes. If cron syntax isn't something you use often, a free cron expression generator is faster than reasoning through the fields by hand, and testing the expression against today's date before trusting it with a production workflow catches off-by-one mistakes early.
Step 3: Get the timezone right before anything else
This is where most scheduling confusion actually comes from, not from the trigger itself. For self-hosted n8n, the instance-wide timezone is set through the GENERIC_TIMEZONE environment variable; if it's unset, n8n defaults to UTC, which is rarely what you meant when you typed "9 AM." Newer n8n versions also let you set a timezone per workflow, which matters if you're running automations for teams or customers across different regions on the same instance. Check this before you trust a schedule, not after it fires at an unexpected hour, because a workflow that "doesn't work" is very often a workflow running exactly on schedule in the wrong timezone.
Step 4: Activate the workflow
Save the workflow and toggle Active in the top right of the editor. This is the step that's easy to forget because everything else about building and testing a workflow in n8n happens with it inactive, you run nodes manually, inspect output, and iterate. A Schedule Trigger behaves differently: it only starts its clock once the workflow is both saved and switched on. If you've configured everything correctly and nothing is happening, check this first; it's the single most common reason a schedule appears broken when it was never actually running.
Step 5: Guard against overlapping runs
If a single execution of your workflow can take longer than the interval between runs, a slow API call, a large data pull, you risk two instances running at once and stepping on each other, writing duplicate records or racing on the same resource. The simplest guard is a status flag: at the start of the workflow, check a database row or a key-value store for a "currently running" marker, exit early if one's present, and clear it when the run completes. This matters more than it sounds like it would; a workflow that's fine in testing with small data volumes can start overlapping itself the moment real production load shows up.
Step 6: Add an error workflow
A scheduled workflow runs unattended by definition, nobody's watching the editor at 3 AM when the cron fires. Set a dedicated error workflow (configurable in the workflow's settings) that sends a Slack message, an email, or logs to wherever your team actually looks, so a failed run gets noticed the same day instead of three weeks later when someone asks why a report never arrived. Skipping this step is the most common reason scheduled automations quietly stop working and nobody finds out until the downstream impact is already visible.
Common scheduling patterns worth knowing
| Pattern | Trigger setting | Good for |
|---|---|---|
| Every N minutes | Simple interval | Polling an API with no webhook support, syncing a feed |
| Daily at a fixed time | Simple interval, specific time | Daily reports, nightly data cleanup |
| Weekdays only, specific hours | Cron expression (0 9,17 * * 1-5) |
Business-hours reminders, standup digests |
| First of the month | Cron expression (0 0 1 * *) |
Monthly billing summaries, recurring invoices |
When a schedule isn't the right trigger
If the thing you're automating is actually event-driven, a new form submission, an incoming order, a chat message, a Schedule Trigger is the wrong tool even if you could technically poll for it on a timer. Polling wastes API calls and introduces latency equal to your interval; a Webhook node reacting instantly to the real event is both faster and cheaper to run. Our guide to using webhooks in n8n covers that trigger type in the same depth as this one, and it's worth reading both before deciding which fits a given workflow.
Where scheduling shows up in real workflows
Scheduled triggers are the backbone of most recurring-report and batch-processing automations. If you're automating something like recurring invoicing or a social media posting calendar, the Schedule Trigger covered here is exactly what kicks those off. If you haven't picked which LLM provider your scheduled workflow should call for any AI-generated step, our guide to connecting OpenAI to n8n covers that credential setup. For the deploy and uptime side of running scheduled automations reliably, our best n8n workflow templates roundup includes several pre-built scheduled flows worth starting from instead of building one from scratch.
For the full range of cron syntax n8n supports, including seconds-level precision and named months, n8n's own trigger documentation covers edge cases beyond what a getting-started guide needs. Get the timezone and activation steps right first; those two account for nearly every "my schedule isn't working" report we've run into, far more often than anything wrong with the cron expression itself.
Frequently asked questions
What's the difference between the Schedule Trigger and the old Cron node?
The Cron node is the older, now-deprecated way to run a workflow on a timer; the Schedule Trigger replaced it and does the same job with a cleaner interface, offering both simple interval presets and a raw cron expression field for anything the presets don't cover. New workflows should use Schedule Trigger; if you're maintaining an older workflow that still uses the Cron node, it still works but won't receive new features.
Why didn't my scheduled workflow run at all?
The most common cause by far is that the workflow was never switched to Active. n8n only runs scheduled triggers on saved, active workflows, running it manually in the editor or leaving it inactive means the clock never starts. The second most common cause is a timezone mismatch, the workflow is running exactly on schedule, just not the schedule you expected relative to your local time.
Can I run a workflow more than once a day at specific times?
Yes. The Schedule Trigger supports multiple trigger rules on a single node, so you can add, say, a 9 AM and a 5 PM interval on the same trigger without needing separate workflows. For anything more irregular than a couple of fixed times, a cron expression (e.g. 0 9,17 * * 1-5 for weekdays at 9 AM and 5 PM) is usually cleaner than stacking several interval rules.
How do I stop a scheduled workflow from running twice on top of itself?
This only matters if a single run can take longer than your interval. The cleanest fix is a status check at the start of the workflow, write a 'running' flag to a database or a simple key-value store when a run starts, and have the next run check that flag and exit early if one is already in progress, clearing it when the run finishes.