A Snowflake Dynamic Table target lag is not a downstream readiness signal
An hourly target lag does not prove today's source batch has reached a Dynamic Table. Gate downstream tasks on observed batch freshness.
October 19, 2026
A source lands once each night. A Dynamic Table has an hourly target lag. A downstream task runs at 7 a.m. and assumes it sees the new batch. Some mornings it does; some mornings it processes yesterday's data. The schedule looks reasonable, but no step has actually proved the batch is ready.
A Snowflake practitioner question describes this situation. Snowflake is explicit that target lag is a staleness goal, not a refresh interval or guarantee. Treat it as a service objective to monitor, not as an event that certifies a specific source load.
Give each batch an identity
At ingestion, record a batch ID or source watermark, the source's effective date, load completion time and row count. Carry that marker through the transformation where practical. The downstream task should compare the latest complete source batch with the latest batch represented in the Dynamic Table's output. If they differ, wait or fail safely; do not silently run with old data.
The marker must mean something to the business. “The table refreshed at 06:58” only says a refresh happened. It does not prove the 06:30 source file was included, or that the file was complete. A batch watermark answers that question.
Read refresh evidence and data evidence together
Snowflake's Dynamic Table monitoring guidance describes refresh history, state and actual lag. Use those signals to diagnose why a refresh did not meet its target. Pair them with an output query that checks the batch marker and expected row or key coverage. A successful refresh may legitimately see no new source data; a failed refresh can leave old output available.
Define a bounded waiting policy. For example: poll for the required batch until an agreed deadline, then alert the owner and skip the downstream export. Do not keep retrying indefinitely or deliver stale data without a visible exception. If a manual refresh is part of recovery, document who can trigger it and how they verify the result afterward.
Test the hard mornings
Rehearse late source arrival, partial load, failed refresh, warehouse contention and a source batch that contains zero valid rows. A zero-row batch can be complete; it should not be mistaken for a missing load. The acceptance check therefore needs explicit completion metadata, not a naive “row count greater than zero” rule.
Track the percentage of runs where the required batch was ready by the deadline, delay from source completion to output availability and downstream runs skipped for freshness. Those are meaningful reliability measures for the business team consuming the result.
Adovo’s view
Freshness belongs to the consumer's decision, not the producer's schedule. An hourly target lag is useful operationally, but it does not answer whether this morning's required batch is present.
Name the batch the downstream task needs and give it a completion signal. Then decide whether to run, wait or stop based on the data actually available. A missed deadline should be visible; silently exporting yesterday's result is the more expensive failure.