Scheduled Tasks

Key features

• Advanced Scheduling Logic for Repeatable Jobs: Create Cron jobs based on calendar dates, clock time, frequency, end dates, and across time zones.
• Blackout Dates: Set exceptions for dates when the pipeline should not be invoked, useful for planned outages or holidays.

Prerequisites

Support and limitations

• A Scheduled Task can take up to 10 minutes past the scheduled time to execute. If it misses that window, the task does not execute.
• If a pipeline run is skipped because another instance is already running, the job history shows only the first skip. Subsequent job skips do not appear in the job history.
• If you open a Scheduled Task seconds after updating it, the UI might display the This task is not scheduled to run message, because the update can take time for the Snaplex to compute the next runtime.

Best practices

The Do not start a new execution if one is already active option (available for both Scheduled and Triggered Tasks) prevents a pipeline from running concurrently with a prior, still-active execution of itself. It works best when there's a comfortable margin between how often the Task fires and how long the pipeline actually takes to run: on a multi-node Snaplex, this protection relies on near-real-time coordination between nodes, so a brief window exists where a new execution can start before the Snaplex recognizes that a prior execution is still active elsewhere. The wider the margin between fires and run time, the less that window matters in practice.

This option is less effective for:

• Pipelines scheduled to fire frequently (for example, every minute) whose typical run time is close to, or can occasionally exceed, the interval between fires. The next fire can be evaluated before the Snaplex finishes recognizing that the prior run is still active.
• Pipelines whose run time varies, such as those that depend on upstream systems or data volume, since an occasional slow run narrows the margin even when the schedule is normally safe.
• Scheduled Tasks that start later than planned, for example because of a grace-period delay, a Snaplex restart, or a period of high load, since a late start narrows the margin for that run the same way a long run does.

To keep this option effective:

• Schedule Tasks with enough margin between fires that the pipeline, including its slower runs, reliably finishes well before the next fire is due. Treat Tasks that regularly run close to their interval as a sign the schedule needs to slow down, not just that this option should catch the overlap.
• Design pipelines invoked by Scheduled or Triggered Tasks to be idempotent, so that if an overlapping execution ever does slip through, running the same pipeline twice for the same input doesn't create duplicate records or corrupt state.
• Monitor actual run time against the scheduled interval, for example on the Task Details page or in Monitor, so you can catch a pipeline trending toward its interval before it starts overlapping.
• Treat the Do not start a new execution if one is already active option as reducing, not eliminating, the chance of an overlapping execution, especially for Tasks scheduled at or near the pipeline's typical run time.

Known issues