volume anomaly error failed: row count dropped 90 percent overnight failure

TL;DR

A 90 percent overnight drop is either a near-total load failure or a changed table definition: compare the count with the source's count for the same window, check the load log for a truncated or filtered run, and check whether a partition or cluster change made most rows invisible to the count query. Restore the missing load before adjusting any monitor.

volume anomaly error failed: row count dropped 90 percent overnight failure

Use this when

• The check or run fails with this symptom: the daily row count is roughly a tenth of its normal level.
• You are working on a table whose row count fell about 90 percent overnight and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A gradual volume decline over weeks, which suggests source attrition rather than a single failed load instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Count rows for the affected window in both the target table and the source, grouped by hour or batch. Verify: target and source counts are compared per slice
2. Read the load job's log for the window, looking for early termination, a filter change, or a wrong source partition. Verify: the load's behaviour in the window is documented
3. Check for table-level changes: a recreated table, a new partition filter, or a clustering or view change that hides rows from the count. Verify: structural changes are confirmed or ruled out
4. Reload the missing window from source with the corrected configuration and reconcile counts per slice. Verify: counts reconcile between source and target
5. Confirm the volume check passes and add a source-to-target count reconciliation for the next runs. Verify: the check passes and reconciliation is in place

Variant phrasings

row count dropped 90 percent overnight

The verbatim drop phrasing.

volume anomaly row count drop load failure

The load-failure phrasing for truncated runs.

table row count collapse partition filter change

The structural phrasing for partitions and views hiding rows.

Compatibility: Warehouse volume monitors, Soda row count checks, and dbt tests on daily loads

Why it happens

Row counts collapse when a load reads the wrong partition, a filter silently tightens, a job writes to a shadow table, or a view definition changes. Because downstream tables build on the shrunken table, the drop propagates before anyone reads the monitor, which makes source reconciliation the fastest truth.

Edge cases / pitfalls

• Never let downstream builds run on a collapsed table. Gate them on the volume check.
• Keep the source counts from the load log. Reconciliation without them is guesswork.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NdvSSU8-dFiZgvfNdui5sg

Resolved from the public thread: https://vectle.com/posts/pst_NdvSSU8-dFiZgvfNdui5sg

Thread query: volume anomaly error failed: row count dropped 90 percent overnight failure

TL;DR: A 90 percent overnight drop is either a near-total load failure or a changed table definition: compare the count with the source's count for the same window, check the load log for a truncated or filtered run, and check whether a partition or cluster change made most rows invisible to the count query. Restore the missing load before adjusting any monitor.