Schedule triggers

The five-field cron expression and its IANA timezone, when the first run happens, and how to design a scheduled workflow that tolerates running twice.

A schedule trigger fires on a clock. It carries two things:

  • A five-field cron expression — minute, hour, day of month, month, day of week.
  • An IANA timezone — Europe/Berlin, America/New_York, and so on.
Nightly pickup
0 2 * * *   Europe/Berlin

The timezone is not cosmetic

0 2 * * * in Europe/Berlin and the same expression in UTC are one or two hours apart depending on the season, which is enough to push a nightly job across a day boundary and make it pick up the wrong file.

Pick the timezone the business runs in, not the one your laptop is in. A supplier who drops a file "by midnight" means midnight where they are; a nightly export a partner reads "first thing" means their morning.

The first run is the next matching time

A schedule does not fire when you save it. The first run is the next clock time that matches the expression — so a daily 02:00 schedule saved at 14:00 waits twelve hours, and a schedule saved at 02:01 waits nearly a full day.

If you want to see it work now, run the workflow by hand with a manual trigger rather than editing the cron expression down to every minute and forgetting to put it back.

Every scheduled trigger across your workflows is listed under Integration Studio → Schedules, with the workflow, the rhythm in words, the timezone and its status. Nothing on that page acts on a schedule — pausing, editing and running live on the trigger itself, in the workflow editor.

The next and last firing times shown in Cockpit are worked out in the browser from the expression, not reported by the platform. Treat them as a reading of your cron expression, not as telemetry.

Schedule firings are at-least-once

The platform promises the job runs, not that it runs exactly once. A firing can produce the same run twice — after a recovery, for instance — and unlike event triggers, a schedule has no id to de-duplicate on. A scheduled workflow that writes data has to tolerate the same firing arriving twice.

The practical version of "tolerate":

  • Upsert on a key the data carries — a supplier product id, an order number — rather than appending. Every shipped import template does this, which is why re-running one never creates duplicates.
  • Move the file you processed. A flow that lists an inbox folder, imports each file, and moves it to an archive folder is naturally idempotent: the second firing finds an empty inbox.
  • Record a marker a second run can check, if neither of the above fits.

What does not work is assuming a run is unique because the schedule fires once. Design the write, not the trigger.

Two schedules on one workflow

Nothing stops a workflow carrying more than one schedule trigger, and it is the normal way to express "every weekday at 06:00, and again at 18:00" when one cron expression would be contorted. Each schedule is its own record with its own timezone and its own active flag, so you can pause one rhythm and leave the other running.

Where to go next

  • Triggers — what all four types share, and the manual trigger you will want alongside a schedule.
  • Execution modes — why a firing during a build does not become a run.
  • Failure handling — retries and error routing, so a 03:00 failure is legible at 09:00.
  • Missed runs — firings that never became a run, and replaying them.
Was this page helpful?