elementary data quality test failed error "table anomalies: row count anomaly detected"
Do not widen the anomaly bounds to silence it: open the Elementary test result, read the observed row count against the training window average and standard deviation, and check whether a real load change explains the jump before touching the test configuration. Use when an Elementary-monitored dbt project where a table-level anomaly test fires. Not for a source table whose volume legitimately changed after a
TL;DR
Do not widen the anomaly bounds to silence it: open the Elementary test result, read the observed row count against the training window average and standard deviation, and check whether a real load change explains the jump before touching the test configuration. Elementary flags a table anomaly when the latest metric falls outside the bounds learned from historical values, so a genuine partial load and a stale training window look identical in the alert.
elementary data quality test failed error "table anomalies: row count anomaly detected"Use this when
- The check or run fails with this symptom: Elementary reports table anomalies with a row count anomaly detected message.
- You are working on an Elementary-monitored dbt project where a table-level anomaly test fires 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 source table whose volume legitimately changed after a backfill or a new upstream feed, where the fix is refreshing the training window rather than the pipeline.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.
Steps
- Open the Elementary result for the failing test and note the metric value, the expected range, and the timestamps of the training window. Verify: the observed value and its bounds are recorded, not just the fail status
- Query the source table row count per load for the same window and compare it with the Elementary metric series. Verify: a matching dip or spike in the source confirms a real load change
- Check for a partial or duplicate load on the flagged day in the pipeline run history. Verify: the load event that explains the anomaly is identified or ruled out
- If the load was real and correct, refresh the Elementary training window or set the anomaly sensitivity for that table; if the load was partial, rerun the load instead. Verify: the chosen fix matches the confirmed cause
- Rerun the Elementary tests for that table. Verify: the table anomalies test passes on the corrected data or the refreshed window
Variant phrasings
elementary table anomalies row count anomaly detected
The shorter phrasing focused on the named failure.
elementary data quality test failed row count
The symptom phrasing a searcher tries next.
dbt elementary anomaly test false positive row count
The variant naming the failing stage or tool directly.
Compatibility: Elementary 0.10 and later with dbt 1.5 and later, warehouse-native Elementary tests
Why it happens
Elementary learns normal metric ranges from a trailing window of past values. A partial load, a duplicate load, or a window polluted by an earlier incident moves the observed value outside the learned bounds even when the test itself is configured correctly.
Edge cases / pitfalls
- A training window that includes a previous incident teaches the test that the incident was normal; exclude known bad days instead of widening sensitivity for the whole table.
- Row count anomalies on tables fed by multiple sources need per-source counts first; the aggregate hides which feed moved.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstDTBY6HUUvFx2iGgq8uHRQ