Skip to main content

Flow scheduling settings

Last updated 10/03/2026

Overview​

Flow Scheduling is where you configure how a Flow runs. You can manage the rules for scheduled runs and the rules for handling exceptions during a run.

Flow scheduling settings​

Click Flow Scheduling on the sidebar to open the scheduling settings page, then click Edit to enter edit mode:

Enable scheduled execution and choose a scheduling method​

First, turn on the Scheduled Execution switch as needed. When it's on, the Flow is scheduled according to preset rules. Two configuration methods are supported:

  • Cron expression: uses standard Crontab syntax to precisely define the run time and cycle (for example, 0 0 * * * means running at 00:00 every day).
  • Interval: set the scheduling cycle (such as hourly, daily, or weekly) in an interactive form, and filter dates and times with conditions such as Specified time and Day of Week to meet complex scheduling needs (such as running only at 9:00 on weekdays).

Manual execution: whether or not scheduled execution is on, you can manually trigger a released Flow to control when it runs.

Misfire strategy and handling rules​

If a scheduled run misses its trigger because of a system exception, an incorrect time configuration, or another reason, choose how to handle it with Misfire Strategy: Execute Immediately or Don't execute. Note: if the start time of the task's validity period is earlier than the current time, the system may treat it as a misfire and apply the corresponding strategy automatically.

Validity period settings and constraints​

Validity Period is the time range during which scheduling is valid. The scheduling policy takes effect only within this period.

Configuration constraints:

  • If the scheduling rule has no trigger point within the validity period (for example, the validity period is 1 day but the Flow is configured to run once a week), an error is reported when you save.
  • The validity period only limits the scheduled execution policy. After the validity period ends, you can still run the Flow manually.

Exception handling strategy​

When a task node in a Flow encounters an exception, the system determines failure according to the following rules:

  • If the node has a retry-on-failure policy, it's marked as a failed task node only after all retries are used up without success.
  • A node without retries, or one that still fails after retrying, is marked as failed directly.

When a task node fails, choose how the Flow continues with Exception Handling Strategy:

Execution failed (stop policy)

  • Execution logic: the Flow stops immediately, as follows:

    • Running nodes: forcibly stopped;
    • Nodes not yet run: skipped and no longer triggered.

  • Use case: scenarios that require very high data consistency (such as financial transaction data processing), to prevent the failed node from affecting downstream processes.

Execution continue (continue policy)

  • Execution logic: the Flow ignores the failed node and continues running subsequent nodes.
  • Use case: non-core processes that can tolerate some node failures (such as log statistics), so that the Flow completes as many processing steps as possible.

After you finish the configuration, click Save. The Save scheduling configuration dialog appears, showing an overview of the scheduling configuration and the next few scheduled run times. After you confirm, click Save to finish editing the configuration.

After you finish editing the configuration, you also need to release it for the scheduling to take effect.

Was this page helpful?
On this page