How to Schedule n8n Workflows with Cron: The Complete Guide

Scheduling a workflow in n8n looks simple until you hit a timezone mismatch, a missed execution during a restart, or discover that your schedule silently stopped firing two weeks ago. The Schedule Trigger node is straightforward but has specific behaviors you have to know. This guide covers everything that matters.

The Schedule Trigger Node

The Schedule Trigger replaces the older Cron node in modern n8n versions. It supports four modes: every minute/hour/day/week (simple interval mode), specific day of week or month, specific time of day, or custom cron expression. Most use cases fit the simple modes. Use cron expressions only when the simple modes cannot express your schedule.

Timezone Behavior

n8n evaluates schedules in the timezone set at the instance level via GENERIC_TIMEZONE, or in the workflow-level timezone setting. If these are misconfigured, a 9am daily schedule might fire at 4am local time. Always set GENERIC_TIMEZONE explicitly in your docker-compose or environment, and verify a test schedule fires at the expected local time before relying on it.

For multi-tenant setups where different customers want different schedule times, use the per-workflow timezone option rather than changing the instance default.

Cron Expressions 101

If you need a cron expression, the format is: minute hour day-of-month month day-of-week. Examples: "0 9 * * *" runs at 9:00 every day. "*/15 * * * *" runs every 15 minutes. "0 9 * * 1-5" runs at 9:00 on weekdays. "0 0 1 * *" runs at midnight on the first of each month. Use crontab.guru to verify complex expressions before saving.

The "Active" Toggle Matters

Schedules do not fire unless the workflow is activated. A deactivated workflow with a Schedule Trigger simply does nothing. This is the most common reason a schedule appears to stop working: someone deactivated the workflow for testing and forgot to re-enable it.

Missed Executions During Downtime

If n8n is down when a scheduled execution should have fired, n8n does not catch up automatically. That execution is simply missed. For critical schedules (billing, deadline-sensitive workflows), consider using an external cron service (cron-job.org, GitHub Actions, EventBridge) that calls an n8n webhook instead of using the Schedule Trigger. External cron gives you retries and observability.

External Cron Services vs Schedule Trigger

External cron services like cron-job.org or EventBridge call an HTTPS webhook on your n8n instance at the scheduled time. Benefits: retries on failure, email alerts if the webhook does not respond, independent from n8n uptime. Drawbacks: additional service dependency, needs the webhook to be exposed.

Schedule Trigger benefits: all logic stays in n8n, no external dependencies, works on fully-internal deployments. Drawbacks: missed executions during downtime, no built-in alerting on failure.

Schedule Frequency Best Practices

Do not schedule workflows more frequently than they actually need to run. Every-minute schedules are often a sign that the workflow should be webhook-triggered instead. Every-minute schedules generate 1,440 executions per day per workflow, which adds up fast on cloud pricing.

For data syncs, once per hour is usually enough. For daily reports, pick a time outside business hours to reduce load. For monitoring workflows, every 5 to 15 minutes is fine. For anything less frequent than hourly, use once per day at a specific time rather than every N hours (easier to reason about).

Preventing Overlapping Executions

If a scheduled workflow takes longer than its interval to complete, the next scheduled run may start while the previous one is still running. This can cause data corruption or duplicate processing. n8n has a setting to prevent concurrent executions of the same workflow; enable it for schedules that might overrun.

Monitoring Schedule Health

Track the last-run timestamp of every scheduled workflow. A workflow scheduled for hourly but last ran 6 hours ago is broken. Set up a monitoring workflow that queries the n8n API (or your execution database) for workflows that have not run recently, and alert if any are stale.

Alternatively, have every scheduled workflow write a heartbeat to a monitoring service (Uptime Kuma, Healthchecks.io) at the end of each successful run. Configure the monitor to alert if the heartbeat stops. This is the most reliable way to catch silent failures.

Testing Scheduled Workflows

Do not wait for the actual schedule to test. Use the "Execute Workflow" button with manual input to verify the logic works. Then set the schedule to fire in 2 minutes and wait; verify it fires on time. Then set the final schedule. Testing with the real schedule catches timezone bugs that manual execution misses.

For workflows that will run at 3am, add temporary logging so you can confirm the first few runs worked as expected without having to be awake.