Every morning at 6 AM, someone manually runs the inventory sync.
They've been doing it for two years. When they're sick, it doesn't happen.
Last week they were on vacation. Nobody noticed until the warehouse ran out of stock.
What if the system just did it automatically, on schedule, every single time?
FOUNDATIONAL - Time doesn't forget. Schedules run whether you're watching or not.
A time-based trigger is a scheduler that fires at specific times or intervals. Instead of someone clicking a button every morning, the system knows: at 6 AM every weekday, run this workflow. The trigger activates, the workflow runs, and nobody has to remember.
The most common format is cron - a decades-old syntax that lets you express complex schedules in a single line. '0 6 * * 1-5' means 6:00 AM, Monday through Friday. Once set, it just works.
Time-based triggers remove humans from repetitive timing decisions. The schedule runs whether anyone remembers or not.
Time-based triggers solve a universal problem: how do you make something happen reliably at specific times without human intervention?
Define a schedule expression. The scheduler watches the clock. When the time matches, it fires the trigger. The trigger starts a workflow. The workflow runs to completion. Repeat forever.
Pick a preset or build your own expression. The preview shows exactly when your schedule will run.
* = any, */5 = every 5, 1-5 = range, 0,30 = specific valuesRun every N minutes/hours
The simplest form: run every 5 minutes, every hour, every day. Easy to understand but limited flexibility. Great for polling or regular syncs.
Precise control over when things run
Five fields define when to run: minute, hour, day of month, month, day of week. '30 9 * * 1' means 9:30 AM every Monday. Complex but powerful.
Tied to business calendars
Run on business days only, skip holidays, respect timezone changes. More complex but handles real-world scheduling needs.
The warehouse system updates overnight as shipments arrive. By 6 AM when the team starts, the inventory data needs to be in the main system. A time-based trigger at 5 AM starts the sync automatically - no human required.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
You schedule a report for 9 AM. But whose 9 AM? The server is in UTC. Your users are in EST. The report arrives at 4 AM their time. Or worse: daylight saving time shifts everything by an hour twice a year.
Instead: Always store schedules in UTC and convert for display. Or use timezone-aware scheduling libraries that handle DST automatically.
The sync job runs every 5 minutes. Usually it takes 2 minutes. One day, the API is slow and it takes 7 minutes. Now you have two instances running simultaneously, both trying to update the same records. Chaos.
Instead: Use locks or semaphores. Before starting, check if the previous run is still active. Either skip this run or queue it.
The 6 AM job failed. Nobody noticed until 2 PM when the data was stale. By then, you've missed half a business day and customers are complaining.
Instead: Every scheduled job needs monitoring. Alert on failure. Have a recovery plan. Consider retry logic for transient failures.
You've learned how to start workflows on a schedule. The natural next step is understanding how to start workflows when events happen - real-time triggers that respond to actions in your systems.