What causes Test Failure: dbt_utils.at_least_one?

An upstream pipeline failed or delivered no data, resulting in the source table being empty for the tested period. A model's WHERE clause or incremental filter excluded all rows — e.g., a date filter that produced no results for the current run window. A seed file was accidentally deleted or the seed load failed, leaving the seed table empty. The column being tested is entirely NULL due to a JOIN that returned no matches. A schema migration removed the column or renamed it, causing the model to produce all-NULL values for the expected column

How do I fix Test Failure: dbt_utils.at_least_one?

Run `SELECT COUNT(*) FROM ` directly in the warehouse to confirm the table is empty or the column is all-NULL.. Trace back through the model's upstream dependencies with `dbt ls --select + ` to find which upstream model or source delivered empty data.. Check the incremental filter logic — if the model uses `is_incremental()`, verify the date range or filter condition produces rows for the current run.. Review the upstream pipeline run history (ADF, Fivetran, etc.) to determine whether the source table was loaded on schedule.. If the table is intentionally empty in some environments (e.g., dev), add a `where:` config to limit the test to production only.

High severitydata quality

Power BI Refresh Error:
Test Failure: dbt_utils.at_least_one

What does this error mean?

dbt's dbt_utils.at_least_one test found that a model or column contains zero non-NULL rows. This test asserts that a table is not empty and that the tested column has at least one populated value — catching silent empty-table scenarios that would otherwise go undetected.

Common causes

1An upstream pipeline failed or delivered no data, resulting in the source table being empty for the tested period
2A model's WHERE clause or incremental filter excluded all rows — e.g., a date filter that produced no results for the current run window
3A seed file was accidentally deleted or the seed load failed, leaving the seed table empty
4The column being tested is entirely NULL due to a JOIN that returned no matches
5A schema migration removed the column or renamed it, causing the model to produce all-NULL values for the expected column

How to fix it

1Run `SELECT COUNT(*) FROM <model>` directly in the warehouse to confirm the table is empty or the column is all-NULL.
2Trace back through the model's upstream dependencies with `dbt ls --select +<model_name>` to find which upstream model or source delivered empty data.
3Check the incremental filter logic — if the model uses `is_incremental()`, verify the date range or filter condition produces rows for the current run.
4Review the upstream pipeline run history (ADF, Fivetran, etc.) to determine whether the source table was loaded on schedule.
5If the table is intentionally empty in some environments (e.g., dev), add a `where:` config to limit the test to production only.

Frequently asked questions

How is dbt_utils.at_least_one different from dbt_utils.not_empty_string?

`at_least_one` checks that at least one row in the column is non-NULL. `not_empty_string` checks that string values are not empty strings. Use both if you need to guard against NULLs and empty strings.

Can I apply at_least_one to the entire model rather than a single column?

Apply it to a non-nullable primary key column (e.g., `id`) to effectively assert the table is not empty. If the primary key column has at least one value, the table has at least one row.