Core Concepts

Dagster provides three primary conditions optimized for common use cases. Start with one of these rather than building conditions from scratch.

eager()

Executes an asset whenever any dependency updates. Also materializes partitions that become missing after the condition is applied.

Behavior:

• Triggers immediately when any upstream updates
• Waits for all upstreams to be materialized or in-progress
• Does not execute if any dependencies are missing
• Does not execute if any dependencies are currently in-progress (waits for all deps to finish first)
• Does not execute if the asset is already in-progress
• For time-partitioned assets, only considers the latest partition
• For static/dynamic-partitioned assets, considers all partitions

Full expanded form:

The ~any_deps_in_progress() guard is critical: it prevents the asset from firing until ALL upstream deps have finished materializing. Without it, the asset would fire each time an individual dep completes, causing redundant executions when multiple deps update in quick succession (e.g., from the same scheduled job).

Use when: You want updates to propagate downstream immediately without waiting for a schedule.

on_cron()

Executes an asset on a cron schedule after all dependencies have updated since the latest cron tick.

Behavior:

• Waits for a cron tick to occur
• After the tick, waits for all dependencies to update since that tick
• Once all dependencies are updated, executes immediately
• For time-partitioned assets, only considers the latest partition Full expanded form:

Use when: You want scheduled execution but only after upstream data is ready. More intelligent than simple schedules.

on_missing()

Executes missing asset partitions when all upstream partitions are available.

Behavior:

• Only materializes partitions that are missing
• Only considers partitions added after the condition was applied (not historical)
• Waits for all upstream dependencies to be available
• For time-partitioned assets, only considers the latest partition Full expanded form:

Use when: You want to fill in missing partitions as upstream data becomes available. Good for backfilling or catching up.

Identifying Built-in vs Custom Conditions from the API

When debugging DA behavior — via the Dagster Plus MCP server’s get_asset tool when it is connected, or dg api asset get otherwise — the automation_condition.expanded_label field shows the condition tree as a list of strings. Compare this against the full expanded forms above to determine if the asset is using a built-in condition or a custom one with missing guards. When you see a condition that looks similar to but doesn’t match a built-in, always identify the missing sub-conditions and explain how their absence changes behavior.

Evaluation by Sensor

The AutomationConditionSensorDefinition evaluates conditions at regular intervals.

Default sensor: A sensor named default_automation_condition_sensor is created automatically in code locations with automation conditions.

Configuration:

• Evaluates all conditions every 30 seconds
• Must be toggled on in the UI under Automation → Sensors
• Launches runs when conditions evaluate to true

Important: If the sensor is not enabled, conditions will not be evaluated and no runs will launch.

Basic Customization

All three main conditions are built from smaller components and can be customized.

Modifying conditions

Boolean composition

See customization.md for detailed patterns and examples.

When to Use Declarative Automation

Use declarative automation when:

• Asset-centric pipelines with complex update logic
• Condition-based triggers (data availability, freshness)
• Dependency-aware execution is needed
• You prefer declarative over imperative

Use schedules when:

• Simple time-based execution without dependency logic
• Predictable, fixed-time execution is sufficient

Use sensors when:

• Custom polling logic for external systems
• Imperative actions beyond asset execution
• File watching or API event monitoring