It is not normal for Elementary to completely miss alerting on a model that failed due to a database error (like "permission denied") during a dbt run. Elementary is designed to capture model errors and can alert on them, but there are a few reasons why you might not see an alert: 1. Elementary Version and Table Changes: In recent versions, the

alerts_dbt_models

view has been deprecated and replaced by the

alerts_v2

table for model error tracking. If you are using a newer version, you should check the

alerts_v2

table for entries where `type = 'model'`:

sql    select * from <elementary_schema>.alerts_v2 where type = 'model'

If you are on an older version, you might still have the

alerts_dbt_models

or

alerts_models

tables/views, but these are deprecated in newer releases. If you don't see the expected data, consider upgrading Elementary to the latest version, as older versions may not be fully supported or may have bugs affecting alerting behavior [Model error tracking and table changes](https://slack.com/archives/C02CTC89LAX/p1709972590535749). 2. Table Population and Permissions: If the relevant Elementary tables (like

alerts_v2

,

alerts_dbt_models

, or

alerts_models

) are empty, it could indicate that the error was not registered. This can happen if: - The dbt run did not complete in a way that allowed Elementary to capture the error (for example, if the run was interrupted before Elementary's hooks could execute). - There are permission issues preventing Elementary from writing to its own tables. - The Elementary CLI was not run with the correct sequence or configuration [Table population and troubleshooting](https://slack.com/archives/C02CTC89LAX/p1685549305198579). 3. Check for Data in Elementary Tables: You should check the following tables in your Elementary schema: -

alerts_v2

(for recent versions) -

alerts_dbt_models

and

alerts_models

(for older versions) -

elementary_test_results

(to ensure test results are being captured) If these tables are empty or missing relevant records, it suggests the error was not registered. Also, ensure that the schema and permissions are set up correctly, as misconfiguration can prevent Elementary from recording alerts [Schema and permissions issues](https://slack.com/archives/C02CTC89LAX/p1707906123258189). 4. Known Issues and Workarounds: There have been cases where model errors were not alerted due to bugs or configuration issues. For example, using dbt selectors incorrectly or running dbt commands in the wrong order can cause Elementary to miss model errors. Make sure you are following the recommended sequence: -

dbt run -s elementary

-

dbt test

-

edr monitor ...

And avoid using selectors that might filter out model errors unintentionally [Command sequence and selectors](https://slack.com/archives/C02CTC89LAX/p1685549305198579). Summary: Check the

alerts_v2

table (or `alerts_dbt_models`/`alerts_models` for older versions) in your Elementary schema for records of the error. If the tables are empty, review your dbt/Elementary run sequence and permissions. If you are on an old version, consider upgrading. If the issue persists, it may be a bug or configuration problem. If you need more targeted troubleshooting, sharing your

edr.log

and

dbt.log

files can help pinpoint the issue, as suggested in several support threads.

@kapa.ai that's the order we're using

- dbt run -s elementary
  - dbt test
  - edr monitor ...

but I only need to run

dbt run -s elementary

once, right? to create tables and schema

Yes, you are correct—you only need to run

dbt run -s elementary

once during the initial setup to create the Elementary tables and schema, and then again only when you upgrade the Elementary dbt package (for example, when moving to a new minor version that may introduce schema changes). You do not need to run it before every dbt job or as part of your regular pipeline runs. The on-run-end hooks and the

edr monitor

command will handle updating the tables with new results and alerts after the initial setup. This is confirmed in multiple sources: - “You need to run

dbt run -s elementary

on 2 occasions: 1. When you first install elementary dbt package on an env... 2. When you upgrade to a new Elementary minor version...” [Clarification on when to run dbt run -s elementary](https://slack.com/archives/C02CTC89LAX/p1685412868454149) - “`dbt run --select elementary` is only needed to build the tables on installation or a minor version update. The on-run-end hooks populate these tables.” [On-run-end hooks and when to run elementary models](https://slack.com/archives/C02CTC89LAX/p1741272625948369) - “Running

dbt run --select elementary

on every change was required in the previous versions. Since 0.5.5 (of the dbt package) you only need to run this once on deployment.” [Change in requirement since v0.5.5](https://slack.com/archives/C02CTC89LAX/p1669287068633309) So, your understanding and the order you’re using are correct. You only need to re-run

dbt run -s elementary

if you upgrade the Elementary package or set up a new environment.

If you have checked the

alerts_v2

table and do not see any alert related to the database error (such as "permission denied") for your failed model, this is not the expected behavior—Elementary is designed to capture and alert on model errors. Based on the knowledge sources, here are some possible reasons and troubleshooting steps: 1. Elementary Version: If you are using an older version of Elementary, model error alerting may not be fully supported or may have bugs. Upgrading to the latest version is recommended, as older versions are not actively supported and may not capture all error types. For example, the

alerts_dbt_models

view is deprecated in favor of

alerts_v2

in newer versions, and model error handling has improved over time [Model error tracking and table changes](https://slack.com/archives/C02CTC89LAX/p1709972590535749). 2. Table Population Issues: If the

alerts_v2

table is empty or missing relevant records, it could indicate that the error was not registered. This can happen if: - The dbt run was interrupted before Elementary could capture the error. - There are permission issues preventing Elementary from writing to its tables. - The Elementary CLI was not run with the correct configuration or sequence [Table population and troubleshooting](https://slack.com/archives/C02CTC89LAX/p1685549305198579). 3. Known Gaps: There are scenarios where Elementary may not capture errors if the dbt run fails in a way that prevents the on-run-end hooks from executing. For example, if dbt returns an exit code that stops execution before hooks run, Elementary may not be able to record the error. This limitation has been discussed, and a feature request exists to improve detection of runs that start but do not finish [On-run-end hook limitations](https://slack.com/archives/C02CTC89LAX/p1678871989845689). 4. Permissions and Schema Configuration: Ensure that the user running Elementary has the necessary permissions to write to the Elementary schema and tables. Misconfiguration here can prevent alerts from being recorded [Schema and permissions issues](https://slack.com/archives/C02CTC89LAX/p1707906123258189). Summary: If the

alerts_v2

table does not contain an alert for your model's database error, it is likely due to one of the above issues. Double-check your Elementary version, permissions, and the sequence of your dbt/Elementary commands. If everything appears correct and the issue persists, it may be a limitation or bug in the current version of Elementary, especially if the dbt run failed before Elementary could register the error. If you need further help, sharing your

edr.log

and

dbt.log

files with the Elementary team (as suggested in several support threads) can help diagnose the issue more precisely.