Schedule Triggers
schedule triggers initiate a playbook at a configured time using cron expressions they are ideal for automating repetitive tasks, improving productivity, and reducing human errors for example, you can use a schedule trigger to automatically generate reports, eliminate the need to manually retrieve data, or perform periodic maintenance tasks key benefits automated execution run playbooks automatically at specified intervals without manual intervention flexible scheduling support for various schedule frequencies (minutely, hourly, daily, weekly, monthly, yearly, or custom cron expressions) utc execution with local or utc input schedules run in utc starting in turbine 26 3 0, you can enter the schedule in utc or your local time zone in the trigger panel reliable uses hangfire job scheduler for reliable execution of scheduled tasks creating a schedule trigger to set a cron job for your playbook, follow these steps in a playbook, from the add panel, click and drag schedule to the canvas hover over the plus icon to add it to the canvas the trigger panel will display on the right side of the canvas, where you can configure your schedule trigger configure the schedule trigger time zone use the time zone section to choose how you enter the schedule option label (ui) behavior utc set using utc enter the schedule in utc the current utc clock is shown under the frequency control local set using local time enter the schedule in your local time zone turbine stores the equivalent utc value for execution when set using local time is selected the ui shows local time zone with your offset and zone (for example america/new york ) to change that zone, go to profile & user settings β general a hint states local times are stored as utc equivalents future daylight savings time (dst) changes are not automatically applied under frequency , the cron builder uses the selected zone the panel also shows current utc time and current local time for reference starting in turbine 26 3 0 , your choice of set using utc or set using local time is remembered in the browser (local storage) so you do not have to reselect it every time you open a schedule trigger execution remains utc based on the platform local input is a convenience for authors; dst shifts after you save are not recalculated automatically monthly schedules and utc conversion monthly schedules can shift the day of the month when local time is converted to utc not every month has days 29 , 30 , or 31 , so turbine cannot always resolve those corner cases automatically when a monthly schedule (every month) converts to utc on day 29 , 30 , or 31 , the trigger panel shows a warning that states the converted day and time β for example utc conversion shifts this to 6 30 pm on day 30 of every month since month lengths vary, please review the schedule before saving review the converted day and time, and adjust the schedule if needed, before you save this warning applies to monthly schedules only other frequencies do not show this month length validation schedule type the schedule type is set to cron (this is the only supported schedule type) schedule frequency select the desired time schedule from the following options minutely runs every minute hourly runs every hour at a specified minute (for example, every hour at 15 minutes) daily runs once per day at a specified time (for example, every day at 8 00 am utc) weekly runs once per week on a specified day and time (for example, every monday at 8 00 am utc) monthly runs once per month on a specified day and time (for example, 1st of every month at 12 00 am utc) yearly runs once per year on a specified date and time (for example, january 1st at 12 00 am utc) custom allows you to define a custom cron expression configuration fields depending on the selected schedule frequency, you'll configure minute the minute of the hour (0 59) hour the hour of the day (0 23), in the time zone mode you selected (utc or local) day of week for weekly schedules, select the day (sunday = 0, monday = 1, and so on) day of month for monthly/yearly schedules, select the day (1 31) month for yearly schedules, select the month (1 12) note the ui displays current utc and local times to help you configure schedules correctly custom cron expression for custom schedule type, you can enter a standard cron expression in the format cron expression format minute 0 59 hour 0 23 (utc) day of month 1 31 month 1 12 day of week 0 6 (0 = sunday, 1 = monday, and so on) examples 0 0 every day at midnight utc 0 8 1 every monday at 8 00 am utc 0 0 1 first day of every month at midnight utc /15 every 15 minutes 0 9 17 1 5 every hour from 9 am to 5 pm utc, monday through friday when finished, click save to complete your schedule configuration the schedule trigger is now configured and will execute your playbook according to the specified cron expression detailed example with native actions automating weekly data collection and processing this example demonstrates how to use a schedule trigger combined with native actions (http, condition, loop, transform, and create variables) to automate data collection, processing, and reporting scenario you want to collect data from an external api every monday at 8 00 am, process it, and generate a report the report will either be stored or emailed the playbook ensures that only valid data is processed, and any errors will be logged for review steps step 1 configure the schedule trigger to run every monday at 8 00 am utc in the schedule trigger panel, select weekly select monday as the day of week set the time to 8 0 0 am in the time zone mode you selected ( set using utc or set using local time ) use the current utc and current local time displays to verify your configuration step 2 add an http action to make a get request to an external api that provides data for the report drag the http action into the playbook configure the http action to send a get request to the api endpoint (for example, https //api example com/data https //api example com/data ) include any required headers (for example, authorization tokens) step 3 use the condition action to verify if the api returns valid data drag a condition action into the flow set the condition to check if the api response contains valid data (for example, response\["data"] is not null) step 4 if valid data is present, use a loop action to iterate through each record in the api response drag a loop action into the playbook configure the loop to iterate over the records in the api response (for example, response\["data"] ) step 5 within the loop, apply a transform action to format the data drag a transform action into the loop configure it to extract and format necessary fields such as date , amount , and category from each record step 6 use the create variables action to store the transformed data drag a create variables action into the flow after the transformation create variables for date , amount , category , and so on step 7 depending on the requirement, send the report via email or store it in a database for email, add an email action and configure it to send the report for storage, use an http action or connector to store the report in a database step 8 if the condition in step 3 is not met, log the error and notify the team use the else branch of the condition action to log the error and send a notification example flow schedule trigger executes every monday at 8 00 am utc http action makes a get request to collect report data from an external api condition action checks if the response contains valid data; if not, logs an error loop action iterates over data records returned by the api transform action formats data fields (for example, "date," "amount," "category") create variables action stores the transformed data as variables for further processing final step store the report in a database or send it via email to stakeholders schedule trigger outputs when a schedule trigger executes, it provides the following event data that can be accessed in your playbook event data $event data cron the cron expression that triggered this execution (string) event metadata event type schedule event action cron event fqn turbine schedule cron event source turbine accessing schedule data in playbooks you can access schedule trigger data in your playbook actions examples note schedule triggers do not provide additional data beyond the cron expression the primary use case is to trigger playbooks at specific times rather than passing data best practices choose utc or local input use set using utc or set using local time in the time zone section the platform still executes schedules in utc test your schedule before deploying to production, verify that your schedule triggers at the expected times by checking playbook run history account for dst when you use local time input, saved schedules are stored as utc equivalents future daylight saving changes are not applied automatically use descriptive names give your playbooks descriptive names that indicate when they run (for example, "daily report generator 8 am utc") avoid overlapping schedules be mindful of playbook execution time to avoid overlapping executions if a previous run has not completed monitor execution regularly monitor scheduled playbook executions to ensure they are running as expected and completing successfully use appropriate frequencies choose the minimum frequency needed for your use case running playbooks too frequently can impact system performance handle errors gracefully ensure your scheduled playbooks handle errors appropriately, as they run unattended troubleshooting playbook not executing verify the playbook is published and enabled check that the cron expression is valid verify the schedule time has passed (schedules are evaluated in utc) check playbook run history for any execution errors wrong execution time schedules are evaluated in utc on the platform if you used set using local time , confirm the local zone under profile & user settings β general and review the current utc / local clocks in the trigger panel if you used set using utc , verify the utc values you entered against the current utc time display for monthly schedules, if the utc conversion lands on day 29, 30, or 31, review the warning in the trigger panel and confirm the schedule before saving invalid cron expression verify the cron expression follows the standard 5 field format minute hour day of month month day of week ensure numeric values are within valid ranges (minute 0 59, hour 0 23, and so on) check that special characters ( , , , , / ) are used correctly schedule not saving ensure all required fields are filled in verify the cron expression is valid check for any validation errors displayed in the ui multiple executions verify you do not have duplicate schedule triggers configured check that the cron expression does not match multiple times unintentionally review playbook run history to identify execution patterns