dbt Freshness Check Results Not Visible in DataHub UI – DataHub Customer Support Portal

Area: Ingestion Issues

Sub-Area: dbt Source Ingestion / Assertions

Issue

After running dbt source freshness and generating a sources.json file that shows passing freshness checks, users cannot find those freshness check results anywhere in the DataHub UI. The official documentation states that "We transfer dbt's freshness checks to DataHub's last-modified fields," but the transferred value is not visible in any UI tab — including the Summary, Stats, or Assertions tabs — leaving users uncertain whether ingestion succeeded or whether they are looking in the wrong place.

You Might Be Asking

Where do dbt source freshness check results appear in the DataHub UI after ingestion?
Is the "Status Last Updated" or "Last Updated" field in the Summary tab populated by dbt freshness checks?
Why does my sources.json show status: pass but I see nothing in DataHub?
Do dbt source freshness checks create Assertions in DataHub?
Is run_results.json supposed to capture freshness check results?

Root Cause

There are two distinct behaviors to understand here, both of which contribute to the confusion:

Source freshness checks do not create Assertions. The DataHub dbt ingestion source only creates Assertions from entries in run_results.json whose unique_id starts with test. (i.e., standard dbt schema tests such as not_null, unique, etc.). Source freshness results come from dbt source freshness and are recorded in sources.json, not run_results.json. As a result, even when run_results.json is provided to the ingestion recipe, it will never contain freshness check entries, and no Assertion entities will be created for them.
The max_loaded_at timestamp is stored in a field not shown in the UI. The max_loaded_at value from sources.json is mapped to SchemaMetadata.lastModified in the DataHub metadata model. However, the DataHub UI surfaces DatasetProperties.lastModified — a different field — in its Status/Summary section. Because the freshness timestamp is written to SchemaMetadata.lastModified rather than DatasetProperties.lastModified, it is stored in the backend but is invisible through the web interface.

Error Messages

(No error is raised — ingestion completes successfully, but freshness data is silently not surfaced in the UI.)

Solution

Confirm ingestion completed successfully. Use the DataHub CLI to verify that the lastModified field was in fact ingested at the backend level:
```
datahub get --urn "urn:li:dataset:(urn:li:dataPlatform:dbt,<your-platform-instance>.<your-schema>.<your-table>,PROD)"
```
Look for a lastModified value inside the schemaMetadata aspect. If it is populated with the expected timestamp, the freshness data was ingested correctly — it is simply not displayed in the UI.
Understand the current product gap. As of the time of this writing, dbt source freshness results are not exposed anywhere in the DataHub UI. This is a known gap tracked in the DataHub open-source project (see GitHub issue #15292). There is no configuration option or workaround to surface these results through the UI at this time.
Do not expect Assertions to be created from freshness checks. If your goal is to see assertion-style pass/fail results in DataHub, note that only standard dbt tests (entries in run_results.json with unique_id prefixed by test.) are converted to DataHub Assertions. Source freshness checks are a separate dbt concept and are not processed through the same pipeline. Providing run_results.json from dbt test or dbt build will create Assertions for schema tests only.
Watch for a fix in a future DataHub release. A code change (PR #15491) has been proposed to correctly map the freshness timestamp to DatasetProperties.lastModified so it becomes visible in the UI. Monitor the DataHub release notes and upgrade when the fix is available.

Understanding the "Synced" / "Last Updated" Fields in the UI

For reference, here is what each timestamp field in the DataHub UI actually represents for a dbt asset:

Synced — Derived from systemMetadata.lastModified, which reflects the most recent time any metadata aspect was written to DataHub. This updates on every ingestion run regardless of freshness checks.
Last Updated (DatasetProperties) — Populated by DatasetProperties.lastModified. On a combined Snowflake+dbt view, this value typically comes from the Snowflake aspect, not from dbt freshness data.
dbt freshness (max_loaded_at) — Currently written to SchemaMetadata.lastModified only, which has no corresponding UI display element.

Additional Notes

This behavior applies to DataHub Cloud and open-source deployments using the DataHub dbt ingestion source.
The documentation statement "We transfer dbt's freshness checks to DataHub's last-modified fields" is technically accurate but misleading: the value is stored, just not in a field the UI renders.
If you are on a combined dbt + Snowflake ingestion view, the "Last Updated" timestamp visible in the UI is likely sourced from the Snowflake platform aspect, not from dbt freshness data.
Using run_results.json produced by dbt test vs. dbt build does not affect freshness check behavior — neither will produce freshness Assertions, because freshness results are only in sources.json.
A fix is in progress (see GitHub PR #15491). Until it is released and deployed, the only way to confirm a freshness timestamp was ingested is via the CLI datahub get command inspecting the raw metadata.