1 min lesson
Sensors, schedules and event-driven runs
Compare two rows from "Sensors, schedules and event-driven runs", then say when each one fits.
Step 1 of 2
Something has to pull the trigger. Dagster gives you two: schedules for the clock, sensors for the world.
- Trigger
- Schedule
- Fires on
- A cron-like cadence
- Use it for
- Predictable batch: hourly ingest, nightly rollups
- Trigger
- Sensor
- Fires on
- An external signal it polls for
- Use it for
- New files in S3, upstream freshness, a queue message
- Trigger
- Auto-materialize
- Fires on
- Upstream changing / policy
- Use it for
- Keep an asset current when its inputs move
| Trigger | Fires on | Use it for |
|---|---|---|
| Schedule | A cron-like cadence | Predictable batch: hourly ingest, nightly rollups |
| Sensor | An external signal it polls for | New files in S3, upstream freshness, a queue message |
| Auto-materialize | Upstream changing / policy | Keep an asset current when its inputs move |
Schedules answer “when?”; sensors answer “did something happen?”; auto-materialization answers “is this stale?”
A schedule is the familiar case: run bronze_events at the top of every hour. A sensor is the event-driven one - it polls a source on an interval and launches a run when it sees a new file land, an upstream asset go fresh or an external system signal readiness. Sensors are how you stop polling-by-cron-and-hope and start reacting to actual data arrival.