Time Distribution Size Best Practices

Guidelines for getting reliable signal from Time Distribution Size checks while keeping the noise (and the maintenance) low.

Choose the interval where the data has a rhythm you can state

The right interval is the one where you could finish the sentence "a normal one of these holds between X and Y records". Too fine and normal variation reads as failure; too coarse and a missing period disappears into a total that still looks plausible.

Size the range from real segment counts, not from the average

Look at the actual counts per segment over a representative period and set the bounds just outside the range you observe. Bounds derived from an average will report every ordinary peak and trough.

Account for the segments that are legitimately different

Weekends, holidays, and the first and last segment of a load rarely look like the rest. Either widen the range enough to cover them, or exclude them with a Filter Clause so the bounds can stay tight where they matter.

Pair it with Freshness to cover the period that never arrived

This rule only evaluates segments the data produced, so a day with no rows at all produces no segment and cannot fail. Freshness watches how recent the newest record is, which is the check that notices a feed stopping entirely.

Use Volumetric when the question is about the table, not the timeline

Volumetric tracks how the container's total row count moves over time and needs no bounds to maintain. Reach for Time Distribution Size when the distribution across periods is what matters, not the total.

Coverage does not affect this check

Time Distribution Size always evaluates the counts of its time segments and reports a Shape Anomaly when a count is outside the configured range. Changing coverage does not alter the outcome or produce Record Anomalies.

Scope rows with a filter

When the rule only applies to part of the table (one segment, one channel, one period), express that with a filter clause. The filter removes the out-of-scope rows from evaluation entirely, while coverage does not affect this check.

Route the anomalies to the right people

A failure usually points at the system that produced the value, not at the warehouse. Set an Anomaly Assignee from the team that owns that producer, and tag the check so related checks are easy to find.