“Update skipped alerts” by itself is not an error – it’s just a step

edr monitor

always runs. If there are no relevant alerts to skip, it’s effectively a no‑op. [[GHA monitor thread](https://elementary-community.slack.com/archives/C02CTC89LAX/p1709594996526349?thread_ts=1709594996.526349&cid=C02CTC89LAX)] When you see only this message and no Slack alerts, the common causes in the docs/community are: 1. No new failing results since last run - Elementary only sends alerts for new failures (per dbt invocation). If you run

edr monitor

again without a new failing `dbt test`/`dbt run`, the same issue is treated as already alerted, so nothing is sent. [[Skipped alerts reasons](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199?thread_ts=1696945250.119199&cid=C02CTC89LAX); [“Why it’s not sending alert?”](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829?thread_ts=1684524581.057829&cid=C02CTC89LAX)] - Make sure you run

dbt test

(or

dbt run

with tests) before

edr monitor

, and that this run actually has failures. 2. Alert suppression / de‑duplication - Alerts can be skipped due to suppression interval or because the same issue was already alerted for the latest invocation. [[Skipped alerts reasons](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199?thread_ts=1696945250.119199&cid=C02CTC89LAX)] - Note:

--suppression-interval 0

does not remove all internal de‑duplication; users still see “Update skipped alerts” even with that flag. [[Suppression interval thread](https://elementary-community.slack.com/archives/C08HW57FGN9/p1744113674615389?thread_ts=1744113674.615389&cid=C08HW57FGN9); [“I want a Slack notif for each run”](https://elementary-community.slack.com/archives/C08HW57FGN9/p1747991866131529?thread_ts=1747991866.131529&cid=C08HW57FGN9)] 3. Elementary tables not populated / wrong schema or target - If

elementary_test_results

(or

alerts_*

/

alerts_v2

) are empty or written to a different schema/db because of custom

generate_schema_name

/

generate_database_name

,

edr monitor

will have nothing to alert on. [[Tables empty + custom schema](https://elementary-community.slack.com/archives/C02CTC89LAX/p1688649713861769?thread_ts=1688649713.861769&cid=C02CTC89LAX); [alerts_v2 in wrong schema](https://elementary-community.slack.com/archives/C02CTC89LAX/p1709594996526349?thread_ts=1709594996.526349&cid=C02CTC89LAX)] - In those cases the fix was: - Ensure

dbt test

writes to the same target/schema Elementary expects. - If you override

generate_schema_name

/

generate_database_name

, run

edr monitor

with the correct

--profiles-dir

and, if needed,

--profile-target

(e.g.

--profile-target prod

). [[Custom schema fix](https://elementary-community.slack.com/archives/C02CTC89LAX/p1688649713861769?thread_ts=1688649713.861769&cid=C02CTC89LAX)] 4. Config disabling alerts - Check

dbt_project.yml

for vars like

disable_warn_alerts

,

disable_skipped_model_alerts

,

disable_skipped_test_alerts

, or anything that might stop alerts or results from being written. [[Disable vars discussion](https://elementary-community.slack.com/archives/C02CTC89LAX/p1688649713861769?thread_ts=1688649713.861769&cid=C02CTC89LAX)] To debug your specific case, based on the community guidance: 1. Verify you just ran a failing `dbt test`/`dbt run`. 2. Confirm

elementary_test_results

has recent failures (last run, correct environment). [[GHA debug questions](https://elementary-community.slack.com/archives/C02CTC89LAX/p1709594996526349?thread_ts=1709594996.526349&cid=C02CTC89LAX)] 3. Check that

alerts_*

/

alerts_v2

exist and are in the expected schema. 4. Make sure

edr monitor

is using the same profile/target as your dbt runs (add

--profiles-dir

and

--profile-target

if needed). [[Custom target fix](https://elementary-community.slack.com/archives/C02CTC89LAX/p1688649713861769?thread_ts=1688649713.861769&cid=C02CTC89LAX)] If you share how you run

dbt test

and your exact

edr monitor

command (plus where your Elementary tables live), I can map these checks more concretely to your setup.

There are a few recurring reasons in the docs/community for “dbt tests failing but no Slack alerts” with

edr monitor

. You can walk through these checks: --- ### 1. Make sure Elementary has fresh test results Elementary alerts are based on its own tables, not directly on

dbt test

output. Check in your warehouse (in the Elementary schema, e.g.

<your_schema>_elementary

): -

elementary_test_results

– must contain rows for your latest failing

dbt test

run. -

dbt_tests

– should also have recent rows. -

alerts

/

alerts_dbt_tests

/

alerts_dbt_models

/

alerts_source_freshness

or

alerts_v2

(depending on your version) – these should be populated by

edr monitor

. [[GitLab missing test alerts](https://elementary-community.slack.com/archives/C02CTC89LAX/p1676383019819779?thread_ts=1676383019.819779&cid=C02CTC89LAX); [“tables are empty” threads](https://elementary-community.slack.com/archives/C02CTC89LAX/p1709594996526349?thread_ts=1709594996.526349&cid=C02CTC89LAX)] If

elementary_test_results

is empty or very old, Elementary has nothing to alert on – in that case: 1. Run

dbt run -s elementary

once to (re)create its models. [[Quickstart note](https://elementary-community.slack.com/archives/C02CTC89LAX/p1707906123258189?thread_ts=1707906123.258189&cid=C02CTC89LAX)] 2. Run

dbt test

. 3. Confirm new rows appear in

elementary_test_results

. 4. Then run

edr monitor …

. --- ### 2. Confirm

edr monitor

is using the same profile/target/schema A common issue is that

dbt test

and

edr monitor

point to different targets or schema logic (e.g. custom

generate_schema_name

/

generate_database_name

), so Elementary looks in a schema where there are no results. [[Custom schema / no alerts](https://elementary-community.slack.com/archives/C02CTC89LAX/p1688649713861769?thread_ts=1688649713.861769&cid=C02CTC89LAX); [alerts_v2 in different schema](https://elementary-community.slack.com/archives/C02CTC89LAX/p1709594996526349?thread_ts=1709594996.526349&cid=C02CTC89LAX)] Make sure: - Your

edr monitor

command includes the correct

--profiles-dir

and, if needed,

--profile-target

(e.g.

--profile-target prod

). - When you inspect

elementary_test_results

and

alerts*

tables, they’re in the same database/schema that

dbt test

writes to. --- ### 3. Check that alerts haven’t been disabled in vars In

dbt_project.yml

look for:

yaml vars:   disable_model_alerts: ...   disable_test_alerts: ...   disable_warn_alerts: ...   disable_skipped_model_alerts: ...   disable_skipped_test_alerts: ...

If you want both model and test alerts, and also want warnings, set them like:

yaml vars:   disable_model_alerts: false   disable_test_alerts: false   disable_warn_alerts: false   disable_skipped_model_alerts: true   disable_skipped_test_alerts: true

Then run

dbt run -s elementary

again to recreate the alert views, run

dbt test

, and then

edr monitor

. [[Vars disabling alerts](https://elementary-community.slack.com/archives/C02CTC89LAX/p1690466901158769?thread_ts=1690466901.158769&cid=C02CTC89LAX); [similar fix](https://elementary-community.slack.com/archives/C02CTC89LAX/p1676383019819779?thread_ts=1676383019.819779&cid=C02CTC89LAX)] --- ### 4. Run order:

dbt test

before

edr monitor

, with new failures Elementary only sends alerts for new failures since the last time it sent alerts for that invocation: - Typical sequence: 1.

dbt run -s elementary

(when installing/updating) 2.

dbt run

/

dbt test

3.

edr monitor …

If you run

edr monitor

again without a new failing run, it will not send the same alerts again; logs will just show “Update skipped alerts …”. [[“Why it’s not sending alert?”](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829?thread_ts=1684524581.057829&cid=C02CTC89LAX); [“Update skipped alerts” explanation](https://elementary-community.slack.com/archives/C02CTC89LAX/p1709594996526349?thread_ts=1709594996.526349&cid=C02CTC89LAX)] --- ### 5. Ensure Elementary models weren’t forced to

table

If you have a project‑wide setting like:

yaml models:   +materialized: table

it can break Elementary internals (e.g.,

elementary.alerts_dbt_tests

being materialized as a table and not refreshed during

dbt test

). This caused alerts tables to stay empty until that line was removed and the Elementary schema recreated. [[Materialized table issue](https://elementary-community.slack.com/archives/C02CTC89LAX/p1697784304685269?thread_ts=1697784304.685269&cid=C02CTC89LAX); [similar fix](https://elementary-community.slack.com/archives/C02CTC89LAX/p1686842159294479?thread_ts=1686842159.294479&cid=C02CTC89LAX)] If you have such a global

+materialized: table

, scope it only to your own models, not

elementary

. --- If you can share: - The exact

edr monitor

command you use. - Where

elementary_test_results

and

alerts*

tables live (db/schema). - Any Elementary‑related

vars:

and

models:

blocks from your

dbt_project.yml

. I can point you to the most likely of these issues for your setup.