Incremental vs. Full Refresh Runs in Bruin

Run modes

Three different things in Bruin are called start_date - distinguish them before reading the table:

These three sources map directly to the three ways a run can be triggered:

These rules are schedule-agnostic - they apply identically to @hourly, @daily, @weekly, @monthly, or any cron expression. The window simply tracks the schedule cadence one-for-one (hourly schedule → one-hour window, weekly → one-week, and so on).

The classic "load history once, then incrementals" pattern falls straight out of this: trigger the first run with --full-refresh to absorb history from the pipeline default start_date, then let the schedule take over.

Interval modifiers

To catch late-arriving events or add a lookback/lookahead on top of the runtime interval, use interval modifiers - they shift start_date and end_date by a fixed offset. Set them on the asset (overrides) or the pipeline (default):

# Asset-level: shift this asset's window back 2 hours
interval_modifiers:
  start: -2h
  end: 0h

# Pipeline-level: applies to every asset that doesn't override it
default:
  interval_modifiers:
    start: -1d
    end: 0h

Modifiers only kick in when the run is invoked with --apply-interval-modifiers, so it's an opt-in per run.