What causes Source Freshness Error?

The upstream pipeline (e.g., Fivetran, ADF, Airbyte) that loads source data failed or was delayed. The `loaded_at_field` column configured in sources.yml is not the correct timestamp column for the table. The source table exists but has not received new rows due to no new activity in the source system. The `error_after` threshold is set too tightly for the actual load frequency of the source. Timezone differences between the warehouse and the configured freshness threshold

How do I fix Source Freshness Error?

Check the upstream loading tool (Fivetran, ADF, etc.) to verify whether the source table was loaded in the expected window.. Query the source table directly: `SELECT MAX( ) FROM . ` and compare to current time.. Verify the `loaded_at_field` in sources.yml points to the correct column — it must be a timestamp column that reflects when the row was loaded, not when it was created in the source system.. Adjust the `warn_after` and `error_after` thresholds in sources.yml to match the actual SLA of the upstream pipeline.. If the source is intentionally not updated (e.g., a slow-changing dimension), increase the threshold or disable freshness checks for that source.

Medium severitydbt

Power BI Refresh Error:
Source Freshness Error

What does this error mean?

The `dbt source freshness` check determined that one or more source tables have not been updated within the configured maximum age. dbt compares the latest record's timestamp against the current time and fails if the gap exceeds the `error_after` threshold.

Common causes

1The upstream pipeline (e.g., Fivetran, ADF, Airbyte) that loads source data failed or was delayed
2The `loaded_at_field` column configured in sources.yml is not the correct timestamp column for the table
3The source table exists but has not received new rows due to no new activity in the source system
4The `error_after` threshold is set too tightly for the actual load frequency of the source
5Timezone differences between the warehouse and the configured freshness threshold

How to fix it

1Check the upstream loading tool (Fivetran, ADF, etc.) to verify whether the source table was loaded in the expected window.
2Query the source table directly: `SELECT MAX(<loaded_at_field>) FROM <source_schema>.<source_table>` and compare to current time.
3Verify the `loaded_at_field` in sources.yml points to the correct column — it must be a timestamp column that reflects when the row was loaded, not when it was created in the source system.
4Adjust the `warn_after` and `error_after` thresholds in sources.yml to match the actual SLA of the upstream pipeline.
5If the source is intentionally not updated (e.g., a slow-changing dimension), increase the threshold or disable freshness checks for that source.

Frequently asked questions

Does a source freshness error stop my models from running?

Only if you configure your dbt Cloud job to run `dbt source freshness` with fail-on-error. By default, freshness is a separate check — models still run even if freshness fails.

How do I make freshness errors warn instead of fail?

Use separate `warn_after` and `error_after` thresholds in sources.yml — e.g., `warn_after: {count: 12, period: hour}` and `error_after: {count: 24, period: hour}`.

The `loaded_at_field` shows a recent timestamp but freshness still fails — why?

Check for timezone mismatches — if the warehouse stores timestamps in UTC but `loaded_at_field` is in a local timezone, dbt calculates a false lag. Verify the column is the warehouse load time, not the source event time.

Official documentation: https://docs.getdbt.com/docs/build/sources#snapshotting-source-data-freshness