elementary data quality test failed error table anomalies: row count anomal

Not specified by the original author.

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

1. 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
2. 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
3. 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
4. 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
5. 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

Resolved from the public thread: https://vectle.com/posts/pstDTBY6HUUvFx2iGgq8uHRQ

Thread query: elementary data quality test failed error "table anomalies: row count anomaly detected"

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.

Not specified by the original author.

TL;DR

An Airbyte row count anomaly usually sits in the sync, not the check: open the sync history for the affected stream, compare source and destination counts per stream, and look for a reset, a schema change, or a cursor that stopped advancing. Fix the sync configuration or run a targeted backfill for the stream, then let the check re-evaluate.

how to fix row count anomaly failure error in airbyte sync data quality check

Use this when

• The check or run fails with this symptom: the data quality check on an Airbyte-synced table reports a row count anomaly.
• You are working on an Airbyte sync whose destination row counts trip the quality check 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 check failing on a non-Airbyte pipeline, where sync history and cursors do not apply instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Open the Airbyte sync history for the stream and record attempts, rows emitted, and any resets in the anomaly window. Verify: the sync history for the window is documented
2. Compare per-stream source counts with destination counts to isolate whether one stream or the whole connection drifted. Verify: the anomaly is scoped to a stream or the connection
3. Inspect the stream's cursor field and schema for changes that would stall or duplicate extraction. Verify: cursor and schema state are checked
4. Fix the configuration, clear a stuck cursor deliberately, or run a backfill for the affected window, documenting any reset's impact. Verify: the sync is corrected or the backfill is running with a known scope
5. After the sync completes, reconcile counts again and rerun the quality check. Verify: counts reconcile and the check passes

Variant phrasings

row count anomaly airbyte sync data quality

The verbatim Airbyte anomaly phrasing.

airbyte stream row count mismatch destination

The reconciliation phrasing for per-stream counts.

airbyte cursor stuck row count check failed

The cursor phrasing for stalled extraction.

Compatibility: Airbyte syncs with destination data quality checks on row counts

Why it happens

Airbyte moves data stream by stream with cursors, so a stalled cursor, a stream reset, or a source schema change alters destination counts in ways that look like data anomalies downstream. The quality check sees the destination only; the sync history holds the explanation.

Edge cases / pitfalls

• Resets re-sync full history and can duplicate if the destination write mode is append. Confirm the write mode first.
• Alert per stream, not per connection. One sick stream hides inside a healthy connection total.

Provenance

Resolved from the public thread: https://vectle.com/posts/psta4YSjnBnCieIowbDVTiUw

Resolved from the public thread: https://vectle.com/posts/psta4YSjnBnCieIowbDVTiUw

Thread query: how to fix row count anomaly failure error in airbyte sync data quality check

TL;DR: An Airbyte row count anomaly usually sits in the sync, not the check: open the sync history for the affected stream, compare source and destination counts per stream, and look for a reset, a schema change, or a cursor that stopped advancing. Fix the sync configuration or run a targeted backfill for the stream, then let the check re-evaluate.

Not specified by the original author.

TL;DR

Fix this in synthetic data generator by acting on the exact message first: record the production ratio between the tables before generation, generate the parent table first, derive the child target count from that ratio and the actual parent count generated, and add a ratio check with a tolerance band to the validation step so drift fails the run visibly. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.

row count ratio between tables not preserved

Use this when

• The operation in synthetic data generator fails with this exact message or symptom: row count ratio between tables not preserved.
• The same failure repeats on retry with unchanged inputs.
• Generation, validation or export is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in synthetic data generator, and copy the full message plus the table, column or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: record the production ratio between the tables before generation, generate the parent table first, derive the child target count from that ratio and the actual parent count generated, and add a ratio check with a tolerance band to the validation step so drift fails the run visibly. Verify: the smallest failing scope now completes, or the named column, table or job behaves as the fix predicts.
3. Check the neighbouring tables, columns or jobs that share the same config, schema or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in synthetic data generator on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, distributions or status against the source in synthetic data generator so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Tables generated or sampled independently each hit their own target, and rounding, filtering and failed rows move the ratio between them even when each individual total looks plausible.

Variant phrasings

row count ratio between tables not preserved

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - synthetic data validation error row count ratio between tables not preserved

The how-to phrasing for the same failure in synthetic data generator. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

synthetic data generator troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: synthetic data generator at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pSbKFaBhiljGNn87a5osMg

Resolved from the public thread: https://vectle.com/posts/pst_pSbKFaBhiljGNn87a5osMg

Thread query: synthetic data validation error row count ratio between tables not preserved

TL;DR: Fix this in synthetic data generator by acting on the exact message first: record the production ratio between the tables before generation, generate the parent table first, derive the child target count from that ratio and the actual parent count generated, and add a ratio check with a tolerance band to the validation step so drift fails the run visibly. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.