Time properties are the core scheduling conditions that define when and how DataWorks triggers a scheduled task. These properties include the scheduled time, along with advanced configurations such as instance generation mode, scheduling calendar, rerun settings, and timeout policies. Together, these parameters control a task's trigger rules, execution boundaries, and automatic recovery from errors.
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
-
Double-click the task name. In the Properties > Schedule section on the right, set Scheduling Cycle to Day.
-
Set the scheduled time to 02:00.
Step 2: Set the scheduling policy
-
Set Rerun to Allow Regardless of Running Status.
-
Select Auto Rerun upon Failure, set Retries to
3, and set 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 four dimensions:
-
Scheduling time: Defines the frequency and specific time for task execution.
-
Instance lifecycle management: Determines when an instance is created and its validity period — including instance generation mode, effective period, and scheduling calendar.
-
Execution policy: Defines the behavior of an instance at its scheduled time — 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 runs in the production environment. DataWorks generates recurring instances for each scheduling cycle and uses the scheduled times and dependencies of those instances to drive the automated workflow.
Scheduled time and business date are the two most important baseline time concepts in DataWorks. For details, see Core concepts: Time baselines.
Scheduled time vs. actual running time
The scheduled time is the earliest time a task can begin. The actual start time depends on two conditions being met:
-
All upstream instances have run successfully.
-
Computing resources are available.
If either condition is not met, the task waits.
Scheduling time zone
A task's scheduled time uses the time zone of its workspace region by default. To handle daylight saving time (DST) changes, change the scheduling time zone. For details, see Switch scheduling time zones and Scenario: Impact of daylight saving time changes on scheduled tasks.
Choose a scheduling cycle
DataWorks supports six scheduling cycles. Use the table below to pick the right one.
| Cycle | Use this when | Instance generation | Dry run on non-run days |
|---|---|---|---|
| Minute | Sub-hourly triggers are needed (minimum interval: 1 minute) | One instance per interval within the time window | No |
| Hour | High-frequency sync or near-real-time compute is needed | One instance per interval or at specified time points | No |
| Day | A daily recurring task is needed (most common) | One instance per day | No |
| Week | Weekly summaries or periodic maintenance is needed | One instance per day | Yes — non-selected days are dry run |
| Month | Calendar-month processing is needed (settlements, monthly reports) | One instance per day | Yes — non-selected days are dry run |
| Year | Long-cycle tasks are needed (quarterly summaries, annual audits) | One instance per day | Yes — non-selected dates are dry run |
For cross-cycle dependencies (for example, a daily downstream task that depends on an hourly upstream task), DataWorks resolves them automatically. The downstream instance waits for all corresponding upstream instances for the same business date to complete. For details, see Best practices: Principles and examples of scheduling configurations for complex dependencies.
The cron expression is automatically generated based on your time selection and cannot be manually modified.
Minute scheduling
Use minute scheduling for tasks that must run multiple times per hour. Set a start time, an end time, and a run interval (minimum: 1 minute). Within the specified window, the system generates multiple instances at the fixed interval.
Configuration example
The target node runs every 30 minutes from 00:00 to 23:59.
Instance details
Hour scheduling
Use hour scheduling for high-frequency synchronization or near-real-time computing scenarios.
Instance generation uses the closed interval [Start Time, End Time]. For example, a time range of [00:00, 03:00] with a 1-hour interval generates four instances scheduled at 00:00, 01:00, 02:00, and 03:00.
Two configuration methods are available:
-
Frequency-based trigger: Runs at a fixed interval (such as every hour) within a specified time period.
-
Point-in-time trigger: Runs at one or more discrete, precise time points.
Configuration example
The target task runs every 6 hours from 00:00 to 23:59.
Scheduling details
Four instances are generated each day, running at 00:00, 06:00, 12:00, and 18:00.
Day scheduling
Use day scheduling to run a task once per day at a fixed time — the most common scheduling method. When you create a task, day scheduling is the default, with a scheduled time randomly generated between 00:00 and 00:30.
Configuration example
The target task runs at 13:00 every day.
Scheduling details
Week scheduling
Use week scheduling for business summaries or periodic maintenance that runs on fixed days of the week. An instance is generated every day, but code runs only on the days you select. Instances on non-selected days are automatically set to a successful dry run state — no code runs and no resources are consumed.
Configuration example
The target task runs on Mondays and Fridays. Instances generated on other days are dry run.
Scheduling details
Month scheduling
Use month scheduling for calendar-month data processing such as financial settlements, monthly performance reports, or monthly user behavior analysis. Instances are generated based on the specific days of the month you select. Code runs only on selected days; instances on all other days are dry run.
Configuration example
The target task runs on the last day of each month to perform a settlement.
Scheduling details
When using the data backfill feature for a month scheduling task, the date you select is the business date, where business date = scheduled time − 1 day.
For a task that runs on the first of the month: select the last day of the previous month as the data timestamp.
For a task that runs on the last day of the month: select the day before the last day as the data timestamp.
Any other selection results in a dry run backfill instance.
For dependency scenarios, see Best practices: Principles and examples of scheduling configurations for complex dependencies.
Year scheduling
Use year scheduling for long-cycle tasks such as quarterly summaries, annual audits, or tasks tied to specific holidays. An instance is generated every day of the year, but actual computation runs only on the months and dates you specify. Multiple date combinations are supported — for example, running on the first or last day of each quarter. Instances on all other dates are dry run.
Configuration example
The target task runs on the 1st and last day of January, April, July, and October each year.
Scheduling details
Instance lifecycle management
These settings control whether a task instance is created and whether the scheduling rules are active — they do not control the specific run time of a task.
| Setting | Purpose |
|---|---|
| Instance generation mode | Controls whether configuration changes take effect on the current day or the next day |
| Effective period | Sets the overall valid time range for the scheduling rules |
| Scheduling calendar | Excludes specific dates (such as public holidays or non-trading days) from triggering |
Instance generation mode
After you deploy a node to the production environment, DataWorks generates scheduled instances based on the configured instance generation mode. The mode determines when recurring instances take effect and when dependency updates apply.
-
Changes made during the 23:30–24:00 period take effect on the third day after deployment, regardless of which mode you choose. Avoid making task changes during this window.
-
To ensure an instance generated immediately after deployment runs normally, the task's scheduled time must be at least 10 minutes after the deployment time. Earlier scheduled times result in a dry run.
| Next Day (default) | Immediately After Deployment | |
|---|---|---|
| New tasks | Scheduling starts the next day. To run the task on the current day, use data backfill. | An instance is generated for the current day immediately. Whether it actually runs depends on the relationship between the scheduled time and the deployment time — if the scheduled time is earlier than the deployment time (or within the 10-minute buffer), the instance is dry run. |
| For changing the scheduling cycle of an existing task | Changes take effect the next day. Already-generated instances for the current day are not affected. | The system regenerates future instances based on the latest configuration and replaces the originals. Previously generated historical instances are retained. Changing the scheduling cycle may leave both old and new cycle instances on the same day — assess the impact carefully before deploying. |
| Recommended for | Routine changes; safe default for most scenarios | Urgent fixes only; fully assess risks before using |
You can view the task's latest dependency status on the scheduled tasks page in Operation Center, regardless of which mode you use.
Effective date
Defines the valid time range for automatic task scheduling. After the effective period expires, the task no longer generates instances. Monitor and manage expired tasks on the O&M Dashboard.
Scheduling calendar
DataWorks provides two types of scheduling calendars:
-
Default calendar: Built-in calendar suitable for common scenarios.
-
Custom scheduling calendar: Define a calendar for industries with flexible scheduling requirements (such as finance). Configure the workspaces the calendar applies to, its validity period, and the scheduling behavior on specific dates. For details, see Configure a scheduling calendar.
The scheduling calendar works in combination with other scheduling configurations such as scheduling type and scheduling time.
Execution policy
The execution policy determines how a task behaves after it is triggered.
Scheduling type
| Scheduling type | Behavior | When to use |
|---|---|---|
| Normal | Runs the code and triggers downstream nodes | Standard scheduled tasks in production |
| Skip Execution | When the scheduled time is reached, the instance does not run and its status changes to failed. This blocks downstream nodes. This is equivalent to freezing a node in Operation Center. A paused node displays the freeze icon in Operation Center. Instances generated for a frozen scheduled task are also in a frozen state. | Urgently interrupting a business process. To resume, unfreeze the node. See Freeze and unfreeze tasks. |
| Dry Run | When the scheduled time is reached, the instance status is immediately set to successful (0 seconds runtime). No code runs and no resources are consumed, but downstream nodes are triggered normally. | Taking a node offline temporarily without blocking its downstream dependencies (for example, during planned maintenance) |
Exception and fault tolerance
Exception and fault tolerance settings protect your data pipeline against task failures and runaway tasks.
Timeout definition
Set the maximum allowed running time for a task. If the task exceeds this limit, it is automatically terminated and set to a failed state — preventing a stuck task from blocking the entire workflow.
| Parameter | Value |
|---|---|
| Scope | Recurring instances, data backfill instances, and test instances |
| Default | 3 to 7 days (dynamically adjusted based on system load) |
| Maximum | 168 hours (7 days) |
| Minimum | 1 minute |
A timeout failure does not trigger an automatic rerun.
Rerun settings
Rerun policies automatically recover failed tasks.
Make sure your task is idempotent before enabling reruns (except for tasks where non-idempotency is intentional). For example, useINSERT OVERWRITEinstead ofINSERT INTOin MaxCompute SQL to avoid data duplication when a task is rerun.
Rerun property — controls whether a task can be rerun:
| Option | When to use |
|---|---|
| Allow Regardless of Running Status | Idempotent tasks that can be re-executed without affecting the result |
| Allow upon Failure Only | Tasks where accidentally rerunning a successful run could cause data issues |
| Disallow Regardless of Running Status | Non-idempotent tasks (such as some data synchronization tasks). Selecting this option disables Auto Rerun upon Failure. |
Auto Rerun upon Failure — when a task fails, the system automatically triggers a rerun:
| Parameter | Description | Range |
|---|---|---|
| Retries | Number of automatic retries after a failure | 1–10 |
| Interval | Time between each retry | 1–30 minutes |
FAQ
Why is my task's actual running time different from its scheduled time?
The scheduled time is the earliest the task can start, not a guarantee. Two conditions must be met before the task actually runs: all upstream instances are successful, and scheduling resources are available. If either condition is not met, the task waits.
My upstream task runs hourly and my downstream task runs daily. Can they depend on each other?
Yes. DataWorks supports cross-cycle dependencies. The system automatically resolves them so the downstream task waits for all corresponding upstream instances for the same business date to complete. For details, see Scheduling configuration principles and examples for complex dependency scenarios.
Why doesn't the bizdate variable show Friday's date after I backfilled data for last Friday?
In DataWorks, business date = scheduled time − 1 day. If your task is scheduled to run in the early morning on Saturday, the business date for that run is Friday. When backfilling, select Friday as the data timestamp — not Saturday.
My task writes data. Will it duplicate data if it reruns?
It might. Make the task idempotent by using INSERT OVERWRITE (overwrite) instead of INSERT INTO (append). This ensures that rerunning the task multiple times produces the same result.