n8n Scheduled Tasks: Cron Done Right Without Dropped Runs

Every cron tutorial teaches the syntax. 0 9 * * 1-5 runs weekdays at nine. Great. None of them tell you what happens when that 9 a.m. report workflow takes eleven minutes to finish but you've scheduled it every five. Or that the Cron node they're showing you was deprecated, so the copy-pasted 2023 setup quietly does nothing on a current instance.

This guide covers n8n scheduled tasks cron the way it actually behaves in production: anchored to a real recurring digest you'd ship, with the overlap problem that silently drops runs solved, and the deprecated-node trap flagged. Syntax is the easy part. Scheduling that doesn't lose runs is the part worth your time.

What scheduled workflows are good for

Cron in n8n earns its place on recurring jobs that should never depend on someone remembering:

• A daily or weekly digest pulling from a Sheet, CRM, or analytics source
• Scheduled report generation and delivery (email, Slack, Telegram)
• Periodic data syncs and backups on a fixed cadence
• Polling an API that has no webhook, on a sensible interval
• Cleanup jobs (archiving old rows, expiring stale records)
• Health checks and uptime pings at a steady rhythm

The common thread: work that's time-driven, not event-driven. If an external event should kick it off, you want a webhook, not a schedule.

Use the Schedule Trigger, not the Cron node

Here's the take that'll save someone an afternoon. The standalone Cron node is deprecated. If a tutorial from 2022 or 2023 has you dragging in a node literally called "Cron," stop. The current node is the Schedule Trigger, which absorbed cron functionality and added fixed intervals, time-of-day scheduling, and per-workflow timezone handling. A workflow built on the old Cron node may import and look fine, then never fire on a modern instance, with no loud error to tell you why.

This matters because cron tutorials age badly and people copy them wholesale. When a scheduled workflow "just doesn't run," the deprecated trigger is one of the first things to rule out. Rebuild it on the Schedule Trigger and the mystery usually evaporates.

The scheduled digest pipeline

Schedule Trigger (cron: 0 8 * * 1)   ← Monday 08:00, configured timezone
        │
        ▼
   Lock check: did the previous run finish?  (skip if still running)
        │
        ▼
   Pull data (Google Sheets / CRM / analytics)
        │
        ▼
   Summarize (OpenAI) → digest body
        │
        ▼
   Deliver (Slack / Gmail) + log run timestamp

Anchoring cron to a shipped digest is the point. A schedule in the abstract teaches nothing; a Monday-morning summary that reads your strategy tracker and writes the week's status is a thing you'd actually keep running.

1. Set the trigger and timezone

Add the Schedule Trigger. For a weekly Monday digest, a cron expression of 0 8 * * 1 fires at 08:00. The piece tutorials skip: that 08:00 is in the workflow's configured timezone, not UTC by default. If your instance runs UTC and your team is in New York, the digest lands at 3 a.m. their time. Set the workflow timezone deliberately in workflow settings before trusting the time.

For simple cadences, prefer the Schedule Trigger's interval and time-of-day modes over raw cron. They're harder to get subtly wrong than a five-field expression.

2. Prevent overlap

This is the failure mode the syntax tutorials never mention.

For most digests this is moot because you run them daily or weekly. For high-frequency polls, it's the bug that quietly eats data.

3. Pull the data

A Google Sheets, CRM, or HTTP Request node fetches what the digest reports on. Keep this idempotent: reading is safe to repeat, so if a run is retried, no harm done. Save the destructive work (archiving, deleting) for after a successful read.

4. Summarize and deliver

An OpenAI node turns the raw rows into a readable digest, then a Slack or Gmail node sends it. Parse the model output with a Code node before delivery. Same discipline as every AI workflow: the model returns text, the delivery node wants clean fields, so add the parse step.

5. Log the run

Append a row recording when the run fired and what it sent. This is how you confirm the schedule is actually working, and it doubles as the lock signal from step 2. A scheduled workflow with no run log is a workflow you're trusting blind.

Implementation patterns

Pattern 1 — Interval sized to runtime. The simplest overlap fix is arithmetic. If the workflow's slow runs take eleven minutes, don't schedule it every five.

Schedule Trigger (every 30 min)   ← comfortably > worst-case runtime
  → [workflow body]
  → Log run timestamp

Pattern 2 — Lock guard for short intervals. When you genuinely need frequent runs, gate on a lock.

Schedule Trigger (every 5 min)
  → Read lock (Sheet / workflow static data)
  → If: lock not held?
      true  → set lock → [body] → clear lock
      false → skip (previous run still going)

The lock turns a silent drop into a deliberate skip you can see in the log. That visibility is the whole win.

n8n nodes you'll use most

Getting started

1. Add a Schedule Trigger and choose interval, time-of-day, or a cron expression for the cadence you need.
2. Set the workflow timezone explicitly so the time fires when you expect, not in UTC.
3. Confirm you're on the Schedule Trigger, not the deprecated Cron node, if you imported an old workflow.
4. Size the interval above the workflow's worst-case runtime to avoid overlapping runs.
5. For genuinely frequent jobs, add a lock guard with an If node so overlaps skip instead of dropping silently.
6. Build the body: pull data, summarize with OpenAI plus a Code parse, deliver via Slack or Gmail.
7. Append a run-timestamp log row so you can verify the schedule fires and catch a stalled job early.

Scheduling underpins most recurring automations, so it's worth seeing it in context. The automated data reporting guide builds the report a digest delivers, and the n8n webhook automation guide covers the event-driven alternative for the jobs that shouldn't be on a timer at all. You can also browse the catalog for scheduled-report templates.

Cron syntax takes five minutes to learn and the overlap trap takes one bad week to discover. Skip the bad week: size the interval, set the timezone, log every run. Scheduled workflows are supposed to be the ones you forget about, in the good way.