Skip to content

Before Date Time Troubleshooting

Common problems when creating and running a Before Date Time 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 an invalid Filter Clause expression, a connection problem with the source, 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 Value Equal to the Cutoff Is Flagged

Rows whose value is exactly the cutoff instant appear as anomalies.

Cause: The comparison is strict less-than (<). A value equal to the cutoff does not pass.

Resolution: When the boundary itself should be allowed, set the Date cutoff one second (for timestamps) or one day (for dates) later than the last value you want to accept.

Values That Look Earlier Are Flagged (or Later Values Pass)

The anomaly list disagrees with what the timestamps look like in your source system.

Cause: The cutoff is stored as a UTC instant, and the comparison runs in UTC: values without an explicit time zone are interpreted as UTC instants. When the source data was written in a local or mixed time zone, the comparison shifts by the offset.

Resolution: Compare the values against the ISO-8601 cutoff echoed in the anomaly message (it ends with Z, meaning UTC). If the source column is naive or mixed-zone, normalize it upstream with a Computed Field so every value is an unambiguous instant. See Cutoff and Time Zone Behavior.

Rows With NULL Values Are Not Flagged

Rows with an empty field pass the check even though you expected them to fail.

Cause: This is by design: NULL values pass. Before Date Time only asserts that present values fall before the cutoff.

Resolution: Pair the check with a Not Null check on the same field to also require presence.

The Field Does Not Appear in the Field Picker

The column you want to check is not listed under Field.

Cause: The picker only lists Date and Timestamp fields. Columns stored as strings (or other types) are excluded, even when they hold date-like values.

Resolution: Expose the column as a native Timestamp upstream, or project it through a Computed Field with a Timestamp type, then select that field.

An Edited Check Keeps Behaving the Old Way

You changed the cutoff (or another property) 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 the ones the updated rule no longer flags. See What Happens to Existing Anomalies.

No Anomalies Although Rows Violate the Rule

A Scan ran, rows clearly violate the boundary, but nothing was reported.

Cause: One of three configurations is excluding the violations:

  • The check is in Draft status: Draft checks are not evaluated by Scans.
  • The Filter Clause excludes the violating rows before the comparison runs.
  • Coverage is below 100% and the failing fraction stayed within the tolerance, so the check passed.

Resolution: Confirm the check is Active, test the filter expression against the violating rows, and review the coverage setting. See Coverage and Tolerance.

Expected One Anomaly per Row, Got a Single Rolled-Up One

Many rows failed, but the scan reported one Shape Anomaly instead of per-row Record Anomalies.

Cause: When the number of failing rows exceeds the scan's rollup threshold, the per-row findings are grouped into one rolled-up Shape Anomaly.

Resolution: This is expected behavior; the rolled-up anomaly carries sampled source records. To change the threshold, see Maximum Record Anomalies per Check.