A scheduled trigger is a workflow trigger that starts an automation at predefined times or intervals instead of in response to an external event. In automation and system integration, it is used to run recurring jobs such as hourly data synchronization, nightly exports or monthly reports, based on a clock rather than on activity in a connected application.
Schedules are usually written as cron expressions, fixed intervals or calendar rules, and are evaluated by a scheduler that belongs to the automation platform, the operating system or a cloud service. A scheduled trigger answers the question “when should this run?” and leaves what to process to the steps that follow.
How a scheduled trigger fires
A scheduled trigger fires when a scheduler compares the current time with a stored schedule and finds a match. The scheduler then creates a new workflow run, usually passing the planned execution time as input so that the run knows which period it covers.
Most schedulers check due jobs every few seconds and dispatch them to workers. Precision is therefore seconds rather than milliseconds, and a run may start slightly after its nominal time, especially under load. Workflows should rely on the logical schedule time passed as a parameter, not on the moment the code happens to execute.
The most widespread schedule format is the five-field cron expression: minute, hour, day of month, month and day of week. Some platforms add a seconds or year field. The table below shows typical expressions and their meaning.
| Expression | Meaning | Typical use |
|---|---|---|
*/15 * * * * | Every 15 minutes | Frequent incremental sync |
0 * * * * | At the start of every hour | Hourly data import |
30 2 * * * | Every day at 02:30 | Nightly backup or export |
0 8 * * 1-5 | 08:00 on weekdays | Morning business report |
0 6 1 * * | 06:00 on the first day of each month | Monthly invoicing run |
Types of schedules and their parameters
Scheduled triggers differ in how the timing rule is expressed and which parameters control edge cases. The choice affects readability and behavior around time zones, missed runs and overlapping executions.
| Schedule type | Definition | Best suited for |
|---|---|---|
| Fixed interval | Every N minutes or hours from a start time | Simple recurring syncs |
| Cron expression | Calendar pattern of fields | Specific times and weekdays |
| Calendar rule | Human-friendly rule such as last business day | Finance and payroll processes |
| One-time schedule | A single future date and time | Planned migration or announcement |
Several parameters deserve explicit decisions. Time zone determines whether 02:30 means local time or UTC. Daylight saving transitions can skip or repeat local times once a year. Catch-up behavior decides whether runs missed during downtime execute later. Concurrency policy decides whether a new run may start while the previous one is still active.
| Parameter | Options | Recommended default |
|---|---|---|
| Time zone | UTC or a named local zone | UTC for technical jobs, local zone for business deadlines |
| Missed runs | Skip, run once, run all | Run once, if the job is idempotent |
| Overlap | Allow, skip, queue, cancel previous | Skip or queue for data jobs |
| Jitter | Small random delay | Use when many jobs share the same minute |
| Timeout | Maximum run duration | Shorter than the interval between runs |
Scheduled trigger compared with other trigger types
A scheduled trigger is time-driven, while other triggers are event-driven or based on checking for changes. In integration work, the right trigger depends on how quickly data must move and what the source system supports.
| Trigger type | What starts the run | Latency | Main drawback |
|---|---|---|---|
| Scheduled trigger | Clock time or interval | Up to one full interval | Runs even when nothing changed |
| Polling trigger | Periodic check finds new data | Polling interval | Repeated API calls, rate limits |
| Webhook trigger | Source system sends an event | Seconds | Requires source support and a public endpoint |
| Manual trigger | A person starts the run | On demand | Depends on human attention |
A polling trigger is itself built on a schedule, but it starts a workflow run only when new data appears, whereas a scheduled trigger starts a run every time. Scheduled triggers are the better choice for batch work that should process a whole period at once, such as consolidating a day of transactions or exporting a full report.
Designing reliable scheduled integrations
Reliable scheduled integrations are built so that any run can be repeated safely and can tell exactly which data it covers. Clock-based jobs fail in quiet ways, so their design should assume that runs will sometimes be late, missed or duplicated.
- Process explicit time windows, such as 01:00 to 02:00, instead of “everything since the last run” without a stored watermark.
- Make each run idempotent, using upserts and unique keys, so a rerun does not create duplicates.
- Store a high-water mark, such as the last processed timestamp, after a successful run.
- Alert on missing runs, not only on failed ones, because a stopped scheduler produces no errors.
- Spread start times away from the top of the hour to avoid load spikes on shared APIs.
Interval length should match business need and data volume. Short intervals reduce delay but multiply API calls and empty runs, while long intervals create large batches that can exceed timeouts or API rate limits. When near real-time behavior is required, an event-driven trigger is usually more efficient than a schedule every minute.
Common pitfalls with scheduled triggers
The most frequent problems with scheduled triggers relate to time zones, overlaps and silent failures. They typically appear weeks after deployment, when a clock change or a slow run exposes an unstated assumption.
- Daylight saving gaps cause a local 02:30 job to be skipped or run twice.
- Overlapping runs process the same records concurrently when a job takes longer than its interval.
- Day-of-month confusion arises when both day fields are set in cron, since many implementations treat them as either-or.
- Server time drift on self-managed machines shifts execution unless clocks are synchronized with NTP.
Explained without jargon
A scheduled trigger is an alarm clock for an automated task. Instead of waiting for someone to press a button or for something to happen, the task starts at a set time, such as every night at two o’clock or every Monday morning.
It is perfect for regular chores like backups, reports and data copies. The catch is that the alarm rings whether or not there is work to do, and the task must cope with being late or missed now and then.
A typical use case
A retail chain with forty stores needs sales from its point-of-sale system in the central accounting system each morning. The source system offers no webhooks, so the integration team uses a scheduled trigger at 03:15 UTC every day.
Each run receives the logical date as a parameter and imports exactly the previous business day. Records are written with upserts keyed by receipt number, so a rerun after a network failure creates no duplicates. The overlap policy is set to skip, and an alert fires if no successful run is logged by 05:00.
When a store’s connection was down for two days, the team simply reran the job for the missing dates, and the accounts reconciled without manual corrections.