To record execution results to the Elementary tables when using the open source version, you do not need the CLI just to populate the core tables with dbt run/test/build results. The Elementary dbt package uses on-run-end hooks to automatically upload results to tables like

dbt_run_results

and

elementary_test_results

whenever you run dbt commands such as:

dbt run dbt test dbt build

As long as the Elementary dbt package is installed and the on-run-end hooks are properly configured in your

dbt_project.yml

, these tables will be populated automatically after each invocation. You do not need to run the CLI for this core functionality—CLI is only required for generating reports, sending alerts, or other advanced features. For example, the

dbt_run_results

table is updated at the end of each invocation via the

elementary.upload_run_results

on-run-end hook, and

elementary_test_results

is updated via

elementary.handle_tests_results

[Run results model docs](https://docs.elementary-data.com/dbt/package-models#run-results). If you want to collect dbt source freshness results, for dbt versions 1.8 and above, you need to add the following to your `dbt_project.yml`:

yaml flags:   source_freshness_run_project_hooks: True

This will allow Elementary to automatically collect source freshness results as well. For earlier dbt versions, you need to use the CLI for this specific case [Collect dbt source freshness results](https://docs.elementary-data.com/oss/guides/collect-dbt-source-freshness). Summary: - For standard run/test/build results: just run your usual dbt commands, with the Elementary dbt package and hooks configured—no CLI required. - For generating reports or advanced features: use the CLI. - For source freshness (dbt <1.8): CLI is required for uploading those results. Let me know if you need help with the on-run-end hook configuration!

Your current configuration:

yaml models:   dbt:     elementary:       +schema: elementary

is not correct for enabling the Elementary dbt package. The

elementary

configuration should be at the top level under

models

, not nested under your project name (

dbt

). Here’s what you need to do: 1. Correct the models section Place the

elementary

block directly under

models

, like this:

yaml    models:      elementary:        +schema: elementary

This ensures that all Elementary models are created in the

elementary

schema, as recommended in the documentation [Step-by-step: Install Elementary dbt package](https://docs.elementary-data.com/oss/quickstart/quickstart-cli-package#step-by-step%3A-install-elementary-dbt-package). 2. No additional on-run-end configuration needed If you installed the Elementary dbt package via

packages.yml

and ran

dbt deps

, the package will automatically add the necessary

on-run-end

hooks for you. You do not need to manually add any on-run-end hooks unless you want to customize when they run (e.g., only on certain targets) [Elementary dbt package on-run-end hooks](https://docs.elementary-data.com/dbt/on-run-end_hooks). 3. Run the Elementary models once After correcting your configuration, run:

dbt run --select elementary

This will create the required tables in the

elementary

schema. 4. Run your dbt commands as usual After setup, running

dbt run

,

dbt test

, or

dbt build

will automatically populate the Elementary tables with execution results, as long as the package and configuration are in place. Summary: - Move the

elementary

block to the top level under

models

. - No need to manually add on-run-end hooks unless you want custom behavior. - Run

dbt run --select elementary

once to create the tables. - Future dbt runs/tests will populate the tables automatically. For more details and examples, see the official [Elementary dbt package installation guide](https://docs.elementary-data.com/oss/quickstart/quickstart-cli-package#step-by-step%3A-install-elementary-dbt-package).

The

elementary.job_run_results

table is a view that is populated based on data in the

dbt_invocations

table, which in turn is updated by Elementary's on-run-end hooks after each dbt invocation (such as

dbt run

,

dbt test

, etc.) [Run results model docs](https://docs.elementary-data.com/dbt/package-models#run-results). If you notice that

job_run_results

is not being updated, here are some possible reasons based on the knowledge sources: 1. On-run-end hooks may not be triggered by all commands: The on-run-end hooks that Elementary uses to upload run results and invocation data are not triggered by all dbt commands. Notably,

dbt source freshness

is not supported by on-run-end hooks in dbt-core, so those runs will not be captured in Elementary tables [Slack discussion on dbt source freshness](https://slack.com/archives/C02CTC89LAX/p1685999499802249). 2. Check for disabled hooks or variables: If you have any of the following variables set in your dbt project or job configuration, they will prevent Elementary from uploading results: -

disable_run_results

-

disable_tests_results

-

disable_dbt_invocation_autoupload

-

disable_dbt_artifacts_autoupload

If any of these are set to

true

, the tables will not be updated [Slack discussion on disabled vars](https://slack.com/archives/C02CTC89LAX/p1699310045488249), [Slack discussion on troubleshooting missing results](https://slack.com/archives/C02CTC89LAX/p1703824109693079). 3. Schema or target mismatch: Ensure that the Elementary models and your dbt runs are using the same target/schema. If the Elementary tables are created in a different schema or environment than where your dbt jobs are running, the tables will not be updated [Slack discussion on schema/target mismatch](https://slack.com/archives/C02CTC89LAX/p1677164475554009). 4. Materialization overrides: If you have overridden the materialization of Elementary models in your

dbt_project.yml

, this can prevent tables from being updated correctly. Make sure you have not set a global materialization that conflicts with Elementary's incremental models [Troubleshooting guide](https://docs.elementary-data.com/cloud/guides/troubleshoot). 5. Full-refresh clears tables: If you run

dbt run --full-refresh

including Elementary models, this will clear the incremental tables. Consider excluding Elementary models from full-refresh runs if you want to retain history [Slack discussion on full-refresh](https://slack.com/archives/C02CTC89LAX/p1668519863054579). Action steps: - Double-check that none of the disabling variables are set to

true

. - Ensure your dbt jobs and Elementary models are using the same schema/target. - Make sure you are not running full-refresh on Elementary models unless you intend to clear the tables. - If you are only running

dbt run -m tag:hourly

and not running all models, some invocations may not be captured if the Elementary models are not included in the run. If after checking these points the issue persists, you may want to review your dbt logs for lines like

Elementary: Uploading run results.

to confirm the hooks are running, or reach out to the Elementary team with your logs for further troubleshooting [Slack troubleshooting thread](https://slack.com/archives/C02CTC89LAX/p1703824109693079). Let me know if you need help checking any of these configurations!

If the execution fails on the last command, the Elementary tables in your BigQuery (BQ) schema will not be populated for that command. This is because Elementary relies on the dbt

on-run-end

hooks to upload results to its tables, and these hooks are only triggered if the dbt command completes successfully. If the dbt run or test fails before reaching the end, the

on-run-end

hooks (and thus the Elementary data upload) will not execute for that invocation. This behavior is confirmed in several discussions, where users observed that if a failure occurs before the on-run-end hook, Elementary tables are not updated with the results of that run. For example, if another on-run-end hook fails before Elementary's, the Elementary hook may not be triggered at all, resulting in missing data in the tables. This is especially relevant if you have multiple hooks and one fails before Elementary's hook is reached, or if the dbt process terminates unexpectedly before the hooks can run [Slack thread on on-run-end hooks and failures](https://slack.com/archives/C02CTC89LAX/p1722936228529189). Summary: If the last dbt command fails before completion, the Elementary tables in your BQ schema will not be updated for that run. Only successful completions trigger the data upload via on-run-end hooks.

You are absolutely right—the objective of observability is to monitor both successful and failed pipeline executions. Elementary is designed to do this: it tracks and alerts on both model run failures and test failures, and provides visibility into the status of your dbt runs and models. However, due to how dbt's

on-run-end

hooks work, Elementary can only upload results to its tables after a dbt command completes and the hook is triggered. If a dbt command fails in such a way that the process is terminated before the

on-run-end

hook runs, Elementary cannot record the results of that run, including the failure. This is a limitation of dbt's current hook system, not of Elementary's intent or design. When a model run fails (for example, due to a contract breach or other error), and the dbt process completes and triggers the

on-run-end

hook, Elementary will record the failure and you will see it in the Model Runs tab and receive alerts if configured. But if the process is interrupted or crashes before the hook runs, the failure will not be recorded in the Elementary tables, which is a known limitation discussed in the community [Slack thread on on-run-end hooks and failures](https://slack.com/archives/C02CTC89LAX/p1722936228529189). So, while Elementary's objective is full observability—including both successes and failures—there are technical constraints based on how dbt exposes run results to hooks. This is a common challenge for all dbt observability tools that rely on dbt's hook system.

Yes, if you want your dbt execution to continue even when a test fails, you should set the test's

severity

to

warn

. When a test is configured with

severity: error

, a failure will cause dbt to return a non-zero exit code, which can stop downstream tasks or the entire pipeline—this is especially important in orchestrators like Airflow. Setting

severity: warn

allows the test to fail without stopping the pipeline, and Elementary can still capture and alert on these warnings if configured to do so [Slack: Configure severity for warnings](https://slack.com/archives/C02CTC89LAX/p1665067912877829), [Slack: Alerting on warn severity](https://slack.com/archives/C02CTC89LAX/p1682711757779689). This approach is commonly used when you want to be notified of data quality issues but do not want them to block your data pipeline execution.

Based on the available knowledge sources, setting the test's

severity

to

warn

is the standard and recommended way in dbt (and thus in Elementary) to allow execution to continue even if a test fails. This approach ensures that test failures do not cause dbt to return a non-zero exit code, which would otherwise stop downstream models or the pipeline. There is no mention in the knowledge sources of an alternative built-in method to achieve this behavior—using

severity: warn

is the documented and supported approach for both dbt and Elementary [Slack: Configure severity for warnings](https://slack.com/archives/C02CTC89LAX/p1665067912877829), [Slack: Alerting on warn severity](https://slack.com/archives/C02CTC89LAX/p1682711757779689). If you need more granular control (such as custom logic for skipping or continuing), the knowledge sources do not provide information about other supported mechanisms within Elementary or dbt for this use case.

Yes, you are correct—some tests are critical and should prevent further execution if they fail. In dbt and Elementary, you achieve this by setting the

severity

of those specific tests to

error

. When a test with

severity: error

fails, dbt will return a non-zero exit code, which can stop downstream models or halt the pipeline, depending on your orchestration setup. For less critical tests, you can set

severity: warn

so failures do not block execution but still provide observability and alerts. This approach allows you to differentiate between critical and non-critical tests, ensuring that only failures in critical tests (e.g., primary key uniqueness, essential not_null checks) will stop your pipeline, while other issues are logged as warnings and do not interrupt the workflow [Slack: Configure severity for warnings](https://slack.com/archives/C02CTC89LAX/p1665067912877829), [Slack: Project-level severity discussion](https://slack.com/archives/C02CTC89LAX/p1706126443387969). This is the standard and recommended way to handle critical versus non-critical tests in dbt and Elementary.

No, that is not correct. If you use

severity: error

and a test fails, **the run results will still be recorded in the Elementary tables**—as long as the dbt process completes and the

on-run-end

hooks are triggered. Elementary captures both passing and failing test results (including those with

severity: error

) in its tables such as

elementary_test_results

and

dbt_run_results

after each dbt invocation, provided the hooks run successfully. The only scenario where results would not be recorded is if the dbt process is terminated abruptly (for example, with

--fail-fast

or a crash) before the

on-run-end

hooks can execute. In normal operation, even if a test with

severity: error

fails and causes dbt to exit with a non-zero code, the hooks still run and results are uploaded to the Elementary tables [Slack: on-run-end hooks and failures](https://slack.com/archives/C02CTC89LAX/p1722936228529189), [Slack: test results recording](https://slack.com/archives/C02CTC89LAX/p1673608911131139). So, using

severity: error

does not prevent run results from being recorded, unless the process is interrupted before the hooks can run.

No, that is not correct. According to the knowledge sources, **Elementary records the results of all dbt tests**—including custom tests, in-built dbt tests, dbt-utils, dbt-expectations, and Elementary’s own tests—**as long as the dbt process completes and the on-run-end hooks are triggered**. This means: - If you use custom tests (macros), in-built dbt tests, or dbt-utils tests, and the test fails, the result will be recorded in the Elementary tables (such as

elementary_test_results

and

dbt_run_results

), provided the dbt command finishes and the on-run-end hook runs. - The same applies to Elementary tests: their results are also recorded under the same conditions. - The only scenario where results are not recorded is if the dbt process is terminated abruptly before the on-run-end hooks can execute (for example, due to a crash or certain types of hard failures) [Slack: on-run-end hooks and failures](https://slack.com/archives/C02CTC89LAX/p1722936228529189). Elementary is designed to collect and monitor the results of all dbt tests, not just its own, and this is a key part of its observability approach [Elementary dbt tests documentation](https://docs.elementary-data.com/features/data-tests/dbt-tests), [Slack: All test results in report](https://slack.com/archives/C02CTC89LAX/p1693381395288719). In summary: All test results (custom, dbt-utils, in-built, and Elementary) are recorded in the run tables if the dbt process completes and the hooks run—there is no special difference in this behavior between test types.

Great question—this is a subtle but important point, and the knowledge sources do address it. When a dbt test fails (even with

severity: error

), dbt does not immediately kill the process. Instead, dbt completes the current command, marks the run as failed (returns a non-zero exit code), and then executes any

on-run-end

hooks. This means that, under normal circumstances, Elementary's on-run-end hooks will still run and record the results of all tests—including failures—into the Elementary tables such as

elementary_test_results

and

dbt_run_results

. The only time results are not recorded is if the dbt process is terminated in a way that prevents the on-run-end hooks from running. For example, using the

--fail-fast

flag causes dbt to stop execution immediately upon the first failure, and in this case, the on-run-end hooks do not run, so results are not recorded in the Elementary tables. This is confirmed in the following source: > when you run with

--fail-fast

there are no new entries in the elementary tables/views (i.e.

alerts_dbt_tests

) but there are new entries if you remove

--fail-fast

> [Slack: --fail-fast and on-run-end hooks](https://slack.com/archives/C02CTC89LAX/p1678393339809499) But in a standard dbt run (without

--fail-fast

), even if tests fail, the process completes, the on-run-end hooks are triggered, and Elementary records the results—including failures—into its tables: > Elementary leverages the dbt [results] jinja variable to get the results of all the resources who participated in an invocation. This variable is currently only accessible by dbt at the end of the DAG (in the context of an on-run-end hook). So the answer is that it will alert once the DAG is completed > [Slack: When are results available?](https://slack.com/archives/C02CTC89LAX/p1674071962667739) Summary: - If you run dbt normally (without

--fail-fast

), failed tests are recorded in Elementary tables. - If you use

--fail-fast

or the process is killed before on-run-end hooks, results are not recorded. Let me know if you want more details on how to check if your hooks are running!