Standard scheduling dependencies trigger a downstream node when its direct upstream finishes. Some pipelines need more: a daily summary job may need to wait for all 24 hourly instances from the previous day to complete, or conditions from nodes across multiple workspaces may need to be combined with AND/OR logic. A dependency check node solves these cases by actively polling the status of ancestor nodes across cycles, workflows, and workspaces, then unblocking a downstream node only when all specified conditions are met.
When to use a dependency check node
Use a dependency check node when:
A node must wait for instances from a different scheduling cycle (for example, a daily node waiting for all hourly nodes from the previous day).
Dependencies span multiple workspaces or workflows and cannot be expressed as direct scheduling dependencies.
Conditions from multiple nodes must be combined with AND/OR logic.
A pipeline must time out and fail explicitly rather than wait indefinitely.
For simple cross-workflow or cross-workspace dependencies that do not require cross-cycle logic or AND/OR composition, use scheduling dependencies instead.
Dependency check node vs. standard scheduling dependency
| Attribute | Dependency check node | Standard scheduling dependency |
|---|---|---|
| Trigger method | Actively polls the status of configured check items. Check item nodes do not trigger or modify the status of the dependency check node. | When the target node reaches its scheduled runtime, it checks whether the upstream node has succeeded. |
| DAG visualization | Dependencies are defined inside the node configuration and are not displayed on the DAG. | Displayed as upstream/downstream lines on the DAG. |
| Backfill and rerun behavior | Rerunning or backfilling a check item node does not trigger the downstream node. | Backfilling an upstream node can optionally trigger the downstream node. |
How it works
A dependency check node sits upstream of the node it protects. When it runs, it evaluates a logical expression built from check groups and check items:
Each check item targets instances of one ancestor node within a specific time window.
Check groups aggregate multiple check items. Items within a group and groups between each other are combined using AND or OR.
The node evaluates the full expression and returns a Boolean result —
Trueunblocks the downstream node,Falsekeeps the dependency check node in the Running state until the next check interval or until Max duration is exceeded.
Configure a dependency check node
The configuration has two sections: Check dependencies and Check settings.
Configure check dependencies
Add check groups and check items
Click + Add Item to create a check item. Organize related check items into a check group.
Configure each check item
Task: Search by Output Name, Name, or ID to find and select the ancestor node. Nodes from the same workflow, a different workflow in this workspace, or another workspace (with permissions) are all supported.
ImportantIf the selected node has not been published to the production environment, the following warning appears: The selected node is not published to the production environment. The check may fail at runtime.
Period: Specifies which historical instances of the ancestor node are evaluated at runtime. Select a period type based on the time window you need.
All conditions within a single check item are combined with AND. For example, if you select all hourly instances for the previous day, every one of those 24 instances must succeed for the check item to return True.
Period type Options Description Minute Previous X minutes(X is 0–59)Checks the instance from X minutes before the current time. Previous 0 minutes= the current minute.Hour Previous X hours(X is 0–23)Checks the instance from X hours before the current time. Previous 0 hours= the current hour.Day Previous X days(X is 0–7)Checks instances from X calendar days ago. Previous 0 days= today (all instances since 00:00).Previous 1 day= all instances from the previous calendar day, 00:00–23:59.Week Monday to Sunday of this week,Monday to Sunday of last week,Last Monday...Last SundayChecks all instances within the specified week range. Month First day to last day of this month,First day of this month,Last day of last month, etc.Checks all instances within the specified month range.
Set logical relationships
On the left side of the interface, set the relationship between check groups and between check items within a group:
AND: All related check items or groups must succeed.
OR: At least one related check item or group must succeed.
Configure check settings
At the bottom of the page, configure the polling behavior:
Check interval: How often the node re-evaluates all check items. Minimum:
1 minute/check.Max duration: The maximum total time the dependency check node waits. If conditions are still not met when this duration expires, the node fails. Maximum:
1440 minutes(24 hours). Set this value to prevent downstream pipelines from waiting indefinitely and to surface upstream failures promptly.
Runtime statuses
| Status | Condition |
|---|---|
| Running | Within Max duration, at least one condition is not yet met. The node retries based on the Check interval. |
| Running Succeeded | All conditions are met within Max duration, per the configured AND/OR logic. |
| Failed | Max duration is exceeded and conditions are still not met. Also fails immediately if a required check item (in an AND relationship) points to a non-existent node — the check terminates early without waiting for Max duration. |
Use case: Make a daily node wait for all hourly nodes from the previous day
This example shows how to configure rpt_daily_summary (a daily node) to wait for all 24 instances of ods_hourly_log (an hourly node) from the previous calendar day (00:00–23:59) to succeed before it runs.
Prerequisites
Before you begin, ensure that you have:
A DataWorks workspace with the relevant nodes deployed to the production environment
The necessary permissions to access
ods_hourly_logfromrpt_daily_summary's workspace
Configure the dependency check node
In your workflow, drag a dependency check node upstream of
rpt_daily_summaryand connect them.
Double-click the dependency check node to open its configuration.
Click + Add Item. In the Task field, search for and select
ods_hourly_log.Set Period to
Day, then selectPrevious 1 day. This instructs the node to check all hourly instances ofods_hourly_logfrom the previous calendar day (00:00–23:59) — all 24 of them must succeed.Leave the logical relationship at the default
AND(there is only one check item, so the setting has no additional effect here).In Check settings, configure the polling behavior:
Check interval:
5 minutes/check— if conditions are not yet met, the node waits 5 minutes before checking again.Max duration:
180 minutes— the node will wait a maximum of 3 hours from the daily node's scheduled time. If all hourly instances from the previous day have not succeeded within that window, the dependency check node fails and blocksrpt_daily_summaryfrom starting.
Save and publish the dependency check node.
rpt_daily_summary now waits for all hourly data from the previous day to be ready before it runs.