Time properties are the core scheduling conditions that define when and how DataWorks triggers a scheduled task. They include not only the scheduled time for setting execution timing, but also a set of advanced configurations such as instance generation mode, scheduling calendar, rerun settings, and timeout policies. Together, these parameters form the time behavior plan of a task, controlling its trigger rules, execution boundaries, and automatic recovery from errors. This guide provides an in-depth look at how to configure each time property and how it works, helping you build unattended, stable, and reliable automated data workflows.
Quick start
Scenario: An e-commerce company needs to automatically calculate the previous day's total sales at 02:00 every day. If the task fails due to factors such as network fluctuations, the system should automatically retry it 3 times.
Step 1: Set the scheduled time
Set the schedule: Double-click the task name. In the section on the right side of the task, set Scheduling Cycle to Day.
Set the scheduled time: Set the scheduled time to 02:00.
Step 2: Set the scheduling policy
Set the rerun property: Set the rerun property to You can run again after successful or failed operation..
Auto rerun upon failure: Select Auto Rerun upon Failure, set the number of retries to
3, and set the interval to5 minutes.Keep the default values for the other properties.
Result:
After you deploy the task, the system automatically triggers it at 02:00 every day, starting from the next day (T+1). If the task fails, the system retries it every 5 minutes. The task runs a maximum of 4 times (1 normal run + 3 retries).
How it works
Time property configurations define the entire lifecycle of a scheduled task, from instance generation to execution. They cover the following core dimensions:
Scheduling time: Visually defines the frequency and specific time for task execution.
Instance lifecycle management: Determines when an instance is created and when it is valid. This includes:
Instance generation mode: Controls whether instances are generated on the deployment day or the next day.
Effective period: Sets the overall valid time range for the task.
Scheduling calendar: Used to exclude non-working days (such as holidays).
Execution policy: Defines the behavior of an instance at its scheduled time through the scheduling type — normal run, dry run (skip), or pause.
Exception and fault tolerance: Provides automated handling for task failures and timeouts through timeout definitions and rerun settings.
Scheduling time
The scheduling time controls when a task is planned to run (also called the scheduled time). In the production environment, it determines how often a task node is automatically triggered. Based on the schedule you configure, the system generates the corresponding number of scheduled instances and drives the automated execution of the entire workflow through the scheduled time and dependencies of these instances.
The scheduled time and the business date are the two most important baseline time concepts in DataWorks. For more information, see Scheduling parameters.
Independence of schedules and dependencies
Frequency independence: The scheduling frequency of a task (such as "hourly" or "daily") is determined by its own configuration and is independent of the frequency of its upstream tasks. For example, a daily-scheduled report task can depend on an hourly-scheduled data preparation task. For more information about configuring dependencies between tasks with different scheduling frequencies, see Configure cross-cycle dependencies.
Instance dependency: Dependencies between tasks with different schedules (cross-cycle dependencies) are essentially instance-level dependencies. The system automatically resolves these dependencies and ensures that a downstream instance is triggered only after all upstream instances corresponding to its business date have completed successfully.
Dry run mechanism: To avoid blocking, non-daily tasks (such as weekly, monthly, or yearly tasks) generate a dry run instance on non-execution days. This instance is immediately set to successful without running any code or consuming resources, ensuring that downstream daily tasks can be triggered normally.
Scheduled time vs. actual run time
Scheduled time: The time you set in the schedule settings is the expected start time of the task, which is the earliest time the task can start running.
Actual run time: The actual execution start time of a task depends on both of the following conditions being met:
All upstream instances have completed successfully.
Compute resources are available.
Scheduling time zone
The scheduling time of a task defaults to the time zone of the region where its workspace resides. To change the time zone, see Configure the scheduling time zone to handle scenarios such as daylight saving time transitions. Scheduling time zone FAQ
The following sections provide configuration examples for various scenarios:
Minute schedule
Set the start time, end time, and run interval. The minimum interval is 1 minute. Within the specified time range, the system generates multiple instances at fixed intervals.
Configuration example
The target node is scheduled every 30 minutes within the 00:00 to 23:59 time range each day.
Instance details
The following figure shows the scheduled time and scheduling parameter replacement for instances of a node that is scheduled every 30 minutes.
Hourly schedule
Suitable for high-frequency synchronization or near-real-time computing scenarios.
Instance generation logic: The system calculates scheduled instances based on a closed interval [start time, end time].
Example: If the time range is set to
[00:00,03:00]and the interval is1 hour, the system generates 4 instances with scheduled execution times at 00:00, 01:00, 02:00, and 03:00.
Configuration methods:
Frequency-based trigger: Runs at fixed intervals (such as every hour) within a specified time range.
Time-point trigger: Runs at one or more specific discrete time points.
Configuration example
The target task is scheduled every 6 hours within the 00:00 to 23:59 time range each day.
Scheduling details
The scheduling system generates 4 instances per day and runs them at the scheduled times of 00:00, 06:00, 12:00, and 18:00.
Daily schedule
The daily schedule is the most common scheduling method. It allows you to run a task once a day at a specified time within the effective period. By default, a newly created task uses a daily schedule, and the scheduled time is randomly generated within the 00:00 to 00:30 time range. You can specify a custom run time as needed. For example, you can specify the task to run once a day at 13:00.
Configuration example
Set Scheduling Cycle to Day and set Scheduled Time to 13:00. The system automatically generates the cron expression 00 00 13 * * ?.
Scheduling details
The scheduling system automatically generates instances for the task and runs them. The following figure shows the data processing times for each business date.
Weekly schedule
Suitable for weekly business aggregation or periodic data maintenance tasks.
Instance generation logic: The system generates instances every day within the effective period.
Normal execution: Code logic is triggered on schedule only on the selected run days (such as Monday and Friday).
Automatic dry run: Instances generated on non-selected days (such as Tuesday, Wednesday, Thursday, Saturday, and Sunday) are automatically set to "dry run successful" status. They do not execute any logic or consume compute resources.
Configuration example
If the target task is configured to run on Monday and Friday each week, instances generated on Monday and Friday are scheduled and executed normally, while instances generated on Tuesday, Wednesday, Thursday, Saturday, and Sunday perform a dry run — they are immediately set to successful at the scheduled time without executing any code logic.
The Scheduled Time is set to 13:00, and the system automatically generates the cron expression 00 00 13 ? * 1,5.
Scheduling details
The scheduling system automatically generates instances for the task and runs them.
Monthly schedule
Suitable for scenarios that require data processing on a monthly basis. It is commonly used for core tasks such as financial settlements, monthly performance reports, and monthly user behavior analysis.
Instance generation logic: The system generates instances based on the specific days of the month that you select. One monthly schedule instance represents a complete calendar month.
Normal execution: Code logic is triggered on schedule only on the selected run days (such as the 15th or the last day of each month).
Automatic dry run: Instances generated on non-selected days (such as the 1st through 14th of each month) are automatically set to "dry run" status. They do not execute any logic or consume compute resources.
Configuration example
If the target task is configured to run on the last day of each month for settlement, the instance generated on the last day of each month is scheduled and executed normally, while instances generated on other days perform a dry run — they are immediately set to successful at the scheduled time without executing any code logic.
The Specified Time is set to the 15th of each month and the last day of each month, and the Scheduled Time is set to 02:00. The system automatically generates the cron expression 00 00 02 15,L * ?.
Scheduling details
The scheduling system automatically generates instances for the task and runs them.
When you use the backfill data feature to backfill data for a monthly scheduled task, note that you select the business date for the backfill, and business date = scheduled date - 1.
Examples:
For a task scheduled on the 1st of each month, select the last day of the previous month as the business date when you backfill data.
For a task scheduled on the last day of each month, select the day before the last day of the month as the business date when you backfill data.
If you select any other business date for the backfill, the backfill instance performs a dry run.
For more dependency scenarios, see Monthly scheduling dependency scenarios.
Yearly schedule
Suitable for long-cycle data tasks such as quarterly aggregation, annual audits, or tasks tied to specific holidays.
Instance generation logic: Instances are generated for all 365 days of the year, but real computation is triggered only on the specified months and dates.
Flexible combinations: Cross-month multi-date selections are supported. For example, you can configure the task to run only on the first or last day of each quarter.
Dry run mechanism: On dates that do not meet the execution conditions, instances perform a dry run in seconds without executing any logic or consuming compute resources.
Configuration example
If the target task is configured to run on the 1st and the last day of January, April, July, and October each year, instances generated on these specified dates are scheduled and executed normally, while instances generated on other dates perform a dry run — they are immediately set to successful at the scheduled time without executing any code logic.
The Specified Time is set to the last day of each month, and the Scheduled Time is set to 00:00. The system automatically generates the cron expression 00 00 00 L 1,4,7,10 ?.
Scheduling details
The scheduling system automatically generates instances for the task and runs them.
The cron expression is automatically generated based on the time you select and cannot be manually modified.
Instance lifecycle management
These configurations determine whether task instances are created. They are not concerned with the specific run time of a task, but rather manage at a macro level whether instances should be created and whether the scheduling rules themselves are valid.
Instance generation mode: Determines whether your configuration changes take effect on the current day or the next day. The next-day mode (default) ensures that changes do not interfere with the current day's tasks, enabling a smooth transition. The immediate mode forcibly resets the current day's instances to apply changes. Use it only for urgent fixes after you fully understand and assess the impact.
Effective period: Defines the validity period of the entire set of scheduling rules.
Scheduling calendar: Allows you to associate the schedule with a specific calendar. For example, you can run tasks only on trading days. This provides more flexible control than a weekly schedule.
Instance generation mode
After a node is submitted and deployed to the production environment scheduling system, the platform generates automatically scheduled Auto Triggered Instances based on the Instance Generation Mode configured for the node (including Next Day and Immediately After Deployment). Regardless of the instance generation mode used, you can view the latest dependency information of the task on the Scheduled Tasks page in Operation Center. However, when the scheduled instances take effect or when dependencies are updated depends on the instance generation mode you select, as described below.
To ensure that instances generated immediately after deployment can be scheduled normally without producing "expired dry runs", make sure the scheduled time of the task is at least 10 minutes later than the deployment time. A task executes code logic or regenerates instances based on the latest schedule settings only at effective time points that are at least 10 minutes after deployment.
Regardless of the instance generation mode, changes made during the
23:30~24:00time window take effect on the third day after the node is deployed to the production environment. Avoid making task changes during this time window.
Instance generation mode | Description |
T+1 next day (default) |
|
Instances for the current day are generated immediately after deployment. An instance is triggered normally only if its scheduled time is at least 10 minutes later than the deployment time. If the scheduled time is earlier than this threshold (including past times and times within the buffer period), the instance automatically enters a dry run state (set to successful immediately without executing any code).
|
Differences in how task code and schedule settings take effect: Regardless of the instance generation mode, an instance always reads the latest code of the task at runtime. However, schedule settings (such as scheduling parameters and rerun policies) are frozen into the instance at generation time. If you modify the schedule settings of a task after instances have been generated, the existing instances are not automatically updated and continue to run with the old settings from generation time. To apply changes, you can use Refresh Instance in Operation Center to update the schedule settings of existing instances in place. If you only need a specific run to use the latest settings, you can also backfill data for the task to rerun it with the latest configuration. For more information, see Instance generation mode: Immediately after deployment.
Effective period
Defines the valid time range for automatic task scheduling. After the effective period expires, no more instances are generated, and the task becomes an expired task. You can monitor and manage expired tasks on the O&M overview page.
Scheduling calendar
Used to define the scheduling dates and scheduling method for a task. DataWorks supports the following two types of calendars:
Default calendar: Provided by the platform and suitable for general scenarios.
Custom scheduling calendar: User-defined and suitable for industries and scenarios that require flexible scheduling dates (such as the financial industry). You can configure rules such as the workspaces to which the calendar applies, the validity period of the calendar, and the scheduling method for tasks on specified dates. For more information, see Create a custom scheduling calendar.
Based on the selected scheduling calendar, you need to combine it with Execution policy and Scheduling time and other schedule settings to schedule the task at the specified time.
Execution policy
This configuration defines how a task should be executed when it is triggered.
Scheduling type
The scheduling types supported by DataWorks are listed in the following table.
Scheduling type | Description | Use case |
Normal | Executes code normally and triggers downstream nodes. | A scheduled task running in normal status. The generated scheduled instances also run in normal status. |
Suspend scheduling | The instance does not run and is set to failed when the scheduled time is reached, which blocks downstream nodes. Pausing scheduling is equivalent to freezing in Operation Center. A node with paused scheduling displays a freeze icon | Suitable for urgently truncating a business workflow. When a business workflow does not need to run for a period of time, you can select this scheduling type to freeze the root node of the workflow. When the business needs to resume, you can unfreeze the root node. For more information about unfreezing tasks, see Unfreeze a task. |
Dry Run | The instance is immediately set to successful when the scheduled time is reached (with a duration of | Suitable when a node does not need to run for a period of time and you do not want to block its downstream nodes. |
in Operation Center. The scheduled instances generated by a frozen scheduled task are also in frozen status.Exception and fault tolerance
This is critical for ensuring data pipeline stability by presetting response plans for various possible exceptions.
Rerun property: Determines whether and how the system should automatically retry when a task fails.
Timeout settings: Sets a reasonable maximum duration for a task. If the task exceeds this duration, the system can automatically trigger an alert or terminate the task to prevent a single node from getting stuck and consuming excessive resources.
Timeout definition
Sets the maximum allowed duration for a task to run. If the duration exceeds this value, the task is automatically terminated and set to failed to prevent it from getting stuck and affecting the entire workflow.
Scope: Takes effect for scheduled instances, backfill data instances, and test instances.
Default value: Defaults to 3-7 days. The system dynamically adjusts this value based on the actual workload.
Limits: The maximum manually configurable value is 168 hours (7 days), and the minimum value is 1 minute.
Rerun settings
Rerun policies enable automated recovery from task failures.
When using rerun properties, ensure that tasks are idempotent whenever possible (except for special tasks) to avoid data quality issues after a failed task is rerun. For example, use
insert overwriteinstead ofinsert intoin ODPS SQL development.
Rerun property: Rerun policies enable automated recovery from task failures.
Type
Use case
Allow Regardless of Running Status
Suitable for idempotent tasks that can be repeatedly executed without affecting results.
Do not re-run after successful operation, and re-run after failure.
Prevents data corruption caused by accidentally rerunning a successful task.
Disallow Regardless of Running Status
Suitable for non-idempotent tasks (such as certain data synchronization tasks). After you select this option, the Auto Rerun upon Failure feature is unavailable.
Auto rerun upon failure: When a task fails, the system automatically triggers a rerun.
Parameter
Description
Rerun Times
The number of automatic retries after a failure. Valid values: 1 to 10.
Rerun Interval
The interval between retries. Valid values: 1 to 30 minutes.
NoteFailures caused by timeout do not trigger automatic reruns.
FAQ and best practices
Q: Why is the actual run time of a task different from the scheduled time?
A: The scheduled time is only the "expected" start time of the task. Actual execution requires two additional conditions to be met: ① All upstream dependency tasks have completed successfully. ② Scheduling resources are available. If either condition is not met, the task remains in a pending state.
Q: My upstream task runs hourly and my downstream task runs daily. Can they depend on each other?
A: DataWorks supports dependencies between tasks with different schedules. The system uses a sophisticated dependency resolution algorithm to ensure that a downstream task correctly waits for all its upstream instances to complete before running. For more information, see Configure cross-cycle dependencies.
Q: I backfilled data for last Friday, but the
bizdatevariable does not show Friday's date. Why?A: This is usually because you confused the "business date" with the "run date". In DataWorks, business date = scheduled time - 1 day. When you backfill data for a task scheduled to run on Saturday morning, the business date you should select is Friday.
Q: My task has data write logic. Will data be duplicated when I rerun it?
A: It might. Therefore, we strongly recommend ensuring task idempotency. For data write tasks, use
INSERT OVERWRITE(overwrite) instead ofINSERT INTO(append) to ensure consistent results across multiple reruns.