Skip to content

Automation & Orchestration

Scheduled automation: when time is the reason

Some work should happen at a set time: the nightly sync to accounting, the weekday invoice reminders, the Monday report. Scheduled automation runs it on your calendar, not just a clock, notices when a run is missed and catches it up exactly once, and never lets two runs of the same job overlap.
Discuss your systemSee when to use a schedule ↓
MonTueWedThuFriSatSunserver down01:40–06:05Nightly sync · 02:00✓ ran02:00✓ ran02:00missed02:00caught up06:10✓ ran02:00✓ ran02:00✓ ran02:00✓ ran02:00Invoice reminders · 09:00 weekdaysheldholiday✓ ran+ Mon's✓ ran09:00✓ ran09:00✓ ran09:00Weekly report · Mon 07:00✓ ran07:00

Use the clock when time is the reason

A lot of business automation starts life as a scheduled job: run every night, every hour, every Monday. Some of that is right. Accounting may only accept a nightly import; people read the operations report on Monday morning. Some of it is a workaround for an event nobody captured, and it makes customers wait until the next run.

Scheduled automation is for the first kind. It runs on a calendar that knows your holidays and time zones, records every run, notices a run that didn't happen and catches it up once, and refuses to start a second run while the first is still going.

Schedule or event?

The test: would doing it sooner be better? If yes, it's an event.
Sync finished jobs to accountingSchedule, 02:00Accounting accepts one batch import a night
Overdue invoice remindersSchedule, 09:00 on working daysCustomers expect them in business hours
Monday operations reportSchedule, Monday 07:00People read it at the start of the week
Invoice when a job is completedEventIt should go when the job is done, not tomorrow morning
Reply to a new enquiryEventWaiting for the next run loses the customer

Five rules for runs you can trust

  1. 01

    A missed run is noticed

    Silence is a failure

    If a run doesn't happen, someone hears about it, the same way as if it had failed.

  2. 02

    Catch-up is deliberate

    Once, not twice

    After an outage, the next run processes what was missed exactly once, then the schedule carries on.

  3. 03

    Never two at once

    One run at a time

    If the last run is still going, the next one waits or is skipped by rule, so two runs never write the same records.

  4. 04

    Calendars, not clocks

    Holidays and time zones

    Working days, public holidays, daylight-saving changes and each location's time zone are part of the schedule.

  5. 05

    Every run is recorded

    Started, finished, what it did

    Each run leaves a line: when it started, when it ended, how many records it touched, and whether anything failed.

What scheduled automation hands off

In

Calendar
working days, holidays, time zones
The job
what to run, and its rules
Run history
what already ran
Scheduler
due → lock → run → record

Out

Runs
on time, recorded
Catch-ups
once, after an outage
Alerts
when a run is missed or fails

Worth building when time really is the reason

Good fit

  • Work has to happen at a set time or on a set cadence.
  • Today it's cron jobs or someone remembering on a Monday.
  • A missed run has caused trouble before.

Not the right fit

  • The work should happen as soon as something changes. That's an event.
  • It runs once a quarter and a person can do it.

Where it's built in

Next to scheduled automation

Questions about scheduled automation

Isn't this just a cron job?

A cron job starts something at a time. Scheduled automation also knows your calendar, prevents overlaps, notices missed runs, catches up once and records every run.

What happens during daylight-saving changes?

Schedules are set in each location's local time, so a 02:00 job runs once on the night the clocks change, not twice or not at all.

Can a person run it early?

Yes. A manual run goes through the same lock and record as a scheduled one, so it can't collide with the next scheduled run.

What do you build schedules with?

Often n8n's scheduler for visible business jobs, and Trigger.dev or workers where runs are long or code-heavy. These are starting candidates, not requirements.