Skip to content

Time Distribution Size Troubleshooting

Common problems when creating and running a Time Distribution Size check, their causes, and how to resolve them.

Validation Fails When Creating the Check

Clicking Validate returns an error instead of a success message.

Cause: The rule could not run against the selected data. The most common reasons are a Min Count or Max Count that is missing or not a number, an invalid Filter Clause, or a container that failed to load.

Resolution:

  1. Review the error message: it explains what needs attention.
  2. Check the Filter Clause for typos: it must be a valid SQL WHERE expression for the selected container.
  3. If the message says the container is marked as Unloadable, the container was skipped after repeated operation failures. Follow the steps in Unloadable Container Error.

A Missing Day Is Not Reported

A period with no data at all passes the check.

Cause: Segments are built from the values present in the field. A day with no rows produces no segment, so there is nothing to compare against the range.

Resolution: Add a Freshness check to notice a feed that stopped, and keep this rule for periods that arrived short.

Almost Every Segment Is Reported

The check fires on most of the timeline.

Cause: Usually the interval is finer than the data's rhythm, so ordinary variation falls outside a range sized for the average.

Resolution: Move to a coarser interval, or widen the bounds to the counts you actually observe across a representative period.

Weekends and Holidays Keep Firing

Segments that are legitimately quiet are reported as too small.

Cause: The range applies to every segment equally; it cannot know that some periods are expected to be light.

Resolution: Widen Min Count to cover the quiet periods, or exclude them with a Filter Clause so the bounds can stay tight on the days that matter.

The Anomaly Percentage Looks Wrong

The reported percentage does not match the share of records affected.

Cause: The percentage counts time segments, not records. Three failing days out of thirty is 10%, no matter how many rows are involved.

Resolution: Read the failing segments listed on the anomaly to see the record counts themselves.

The Coverage Slider Has No Effect

Lowering coverage does not stop the check from failing.

Cause: The slider is part of the shared check form, but the rule evaluates segment counts rather than individual rows.

Resolution: Adjust Min Count and Max Count, or scope the rows with a Filter Clause, instead of changing coverage.

An Edited Check Keeps Behaving the Old Way

You changed the configuration but the anomaly list did not change.

Cause: Edits take effect on the next Scan. Saving the check does not re-evaluate the data, and anomalies raised under the previous configuration are not modified.

Resolution: Run a Scan on the container (or wait for the scheduled one). Old anomalies stay open until you triage them or a Full scan with Auto Resolve clears them. See What Happens to Existing Anomalies.

No Anomalies Although the Data Looks Wrong

A Scan ran, the data clearly breaks the rule, but nothing was reported.

Cause: One of these configurations is excluding the violations:

  • The check is in Draft status: Draft checks are not evaluated by Scans.
  • The Filter Clause excludes those rows before the evaluation runs.

Resolution: Confirm the check is Active and test the filter expression against the offending rows.