A scheduled run is missing or processes the wrong interval

Understand the likely causes

• The expectation may assume a data-interval timetable while the deployment uses trigger-time semantics, or the task may substitute wall-clock today for its declared input. Paused scheduling, catchup policy and missing input readiness are separate possibilities.

Identify the resolved timetable and trigger path

Record the DAG's exact schedule, start boundary, timezone, catchup setting and selected timetable behavior. Airflow 3 cron defaults can differ from legacy interval assumptions, so an @daily string alone is insufficient evidence for a particular data range. Distinguish a scheduled run from a manual or asset-triggered run before interpreting context keys. Use existing definition and interface evidence without changing scheduler configuration. A run that has not yet become eligible is different from an eligible run waiting on capacity, and those cases should not be repaired with the same historical rerun.

Compare intended and selected source boundaries

Write the required business interval independently from the task's actual selection. A report for October first should not silently read October third because the worker began late. Check half-open end handling and the business timezone, including calendar boundaries where relevant. For a manual or asset-triggered run without logical_date, interval keys can be absent in Airflow 3; replacing them with now hides a contract failure. Normalize the supported trigger input explicitly and reject missing required context. The offline fixture below shows two different dates without contacting Airflow or reading any source dataset.

intended_partition = '2026-10-01'
worker_start_date = '2026-10-03'
assert intended_partition != worker_start_date
print(intended_partition)

2026-10-01

Separate scheduling eligibility from data readiness

Inspect whether the definition is discovered and unpaused, whether the intended interval is complete under the chosen timetable and whether active-run or resource limits prevent progress. Then examine input readiness separately: a created run does not prove its source manifest exists or is complete. A sensor waiting for the correct interval may be healthy even when a user expected an immediate report. Preserve the exact run and task states with timestamps instead of inferring the cause from one empty grid cell. Do not mark tasks successful to make the interface match an unverified expectation.

Choose the smallest correction that preserves meaning

If timetable semantics are wrong, review the explicit timetable contract and existing historical coverage before an authorized definition change. If the task selected today, repair its interval input normalization and test a delayed historical fixture. If a required interval was genuinely missed, prepare a bounded backfill plan with source coverage, existing-run policy and duplicate-safe output behavior. This guide performs none of those state-changing actions. A date-list or Boolean model is planning evidence only; final acceptance must compare the intended partitions with actual validated artifacts after an independently authorized execution.

Keep it from recurring

• Keep schedule semantics, timezone and source-partition rules in the DAG contract. Use fixed start boundaries and representative interval fixtures. Review timetable and context behavior during upgrades instead of relying on remembered defaults from older releases.