## 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.

```text
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_QMUuz8IlDgUx7WgU41Zwgg