@kapa.ai 1. Is

slack_group_alerts_by

in

+meta

correct, and does it cover model alerts?

On elementary dbt package 0.25.1 with edr 0.25.1 on BigQuery, we set

+meta: {slack_group_alerts_by: table}

in

dbt_project.yml

under both

models:

and

data_tests:

. Manifest confirms 1431/1431 models and 557/557 tests carry it. Two docs pages disagree: the OSS alerts-configuration page names

slack_group_alerts_by

in YAML meta and says it applies to model and test alerts; another says the key is

group_alerts_by

, lives in edr's

config.yml

, and supports test alerts only. Which is correct for 0.25.1, and does grouping apply to model run failures?

slack_group_alerts_by in +meta — What's Correct Based on the knowledge sources, here's what can be confirmed: The correct key is slack_group_alerts_by The documentation and community threads consistently use

slack_group_alerts_by: table

inside the

meta

block — not

group_alerts_by

. This applies in both

.yml

files and

dbt_project.yml

. [OSS Alerts Config] [Cloud Alerts Config] Placement in dbt_project.yml is valid Setting it under

models:

path with

+meta

is the documented approach:

models:
  path:
    subfolder:
      +meta:
        slack_group_alerts_by: table

And similarly under

data_tests:

. [OSS Alerts Config] Does grouping apply to model run failures? The knowledge sources describe

slack_group_alerts_by: table

as grouping all issues associated with a table into a single notification — and the CLI equivalent

--group-by table

is described in the context of both test and model alerts. Community examples show grouped alerts for model errors (e.g.,

"Error: fct_sales_ticks: 1 issues detected"

) appearing in the grouped format. [Slack thread] So in practice, grouping does appear to cover model run failures, not just test alerts. Important caveats about grouped alerts • Grouped alerts intentionally contain less detail per issue — fields like

test_results_sample

,

test_query

, and custom

alert_fields

are not supported in grouped alerts. [OSS Alerts Config] • One community member confirmed that

test_query

only works when

slack_group_alerts_by

is set to

alert

(i.e., non-grouped). [Slack thread] • Do not use the

+

prefix before Elementary-specific meta keys like

owner

or

slack_group_alerts_by

inside the

meta

block — a community member confirmed removing the

+

prefix fixed their issue. [Slack thread] On the version-specific question (0.25.1) The knowledge sources do not explicitly reference version 0.25.1 or confirm whether behavior changed between versions. I cannot confirm with certainty whether there are any version-specific differences for this release. If the manifest confirms the meta is propagated correctly to all models and tests, the configuration itself is syntactically correct per the docs — but if grouping isn't behaving as expected, it may be worth checking the Elementary changelog or opening a GitHub issue. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai Where does edr read that meta from at alert time?

Does

edr monitor

read

slack_group_alerts_by

from the uploaded

dbt_models

/

dbt_tests

artifact tables, or from the manifest / somewhere else? We ask because we have set

disable_dbt_artifacts_autoupload: true

and now refresh artifacts from one scheduled job, so if the meta is read from those tables the config only takes effect after that job runs.

Where edr monitor reads slack_group_alerts_by from The knowledge sources directly confirm this:

edr monitor

reads alert metadata — including

slack_group_alerts_by

— from the Elementary artifact tables in your data warehouse, specifically

dbt_models

and

dbt_tests

. It does not read from the raw manifest at alert time. From a support thread: > "Elementary uploads meta data on the on-run-end hooks (or when you run the elementary models

dbt run --select elementary

). The CLI gets the metadata from these tables." [Slack thread] And from another thread where a user's channel config wasn't being picked up: > "When you execute dbt, elementary on-run-end hooks write the configs from the YMLs to elementary tables in your elementary schema…

edr

reads from the elementary tables in the schema configured in the

profiles.yml

under the elementary profile." [Slack thread] You can verify the meta is present by querying directly:

SELECT name, meta
FROM <elementary_schema>.dbt_models
WHERE name = '<your_model_name>';

Implication for your setup Your understanding is correct. With

disable_dbt_artifacts_autoupload: true

, the

dbt_models

and

dbt_tests

tables are only refreshed when your scheduled artifact job runs (

dbt run --select elementary.edr.dbt_artifacts

). Until that job runs after a config change,

edr monitor

will use whatever

slack_group_alerts_by

value (or absence of it) is currently stored in those tables. [Linen thread] So your scheduled artifact refresh job is the single gate controlling when meta config changes take effect for alerting — which is exactly the expected behavior given your setup. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai Does disabling artifact autoupload degrade alert content? — the one I'd most want answered, because it's a cost we may have taken without noticing.

With

disable_dbt_artifacts_autoupload: true

and artifacts refreshed hourly by a dedicated

dbt run --select elementary.edr.dbt_artifacts

job, do alerts lose or misreport anything between refreshes? Specifically, do alerts join to

dbt_models

/

dbt_tests

for owners, tags, table names, or descriptions — such that a stale or failed refresh produces alerts with missing or wrong metadata rather than an error?

Does disabling artifact autoupload degrade alert content? The knowledge sources partially address this, but do not provide a complete field-by-field breakdown of exactly which alert fields are joined from `dbt_models`/`dbt_tests` at alert time. I'll share what is explicitly confirmed and flag where I'm uncertain. What the knowledge sources confirm Yes, alerts do join to artifact tables for metadata. The docs and community threads are explicit that Elementary's reports and alerts are built by joining runtime results (e.g.

elementary_test_results

) with metadata from artifact tables: > "Elementary's reports and alerts are built by joining runtime results (e.g.

elementary_test_results

) with metadata from artifacts tables (e.g.

dbt_tests

,

dbt_models

). If

dbt_tests

or related tables are empty or outdated, tests may not appear correctly in reports or invocation results." [dbt artifacts] Specifically confirmed as coming from artifact tables: • Owners — read from `dbt_models`/`dbt_tests` meta at alert time [Slack thread] • Tags — stored in artifact tables and used for alert routing/filtering •

slack_group_alerts_by

— read from artifact tables as confirmed in the previous answer • Model/test names and configurations — sourced from artifact tables What happens with stale artifacts between refreshes The knowledge sources confirm the degradation is silent, not an error. Stale artifact tables produce: • Missing metadata on alerts — owners, tags, descriptions reflect the state at the last artifact refresh, not the current project state • New models/tests not appearing — resources added since the last refresh won't show up in alerts at all • Removed resources still appearing — old models/tests may still surface until the next refresh replaces the table > "Config changes (severity, tags, owners, etc.) won't be reflected… Elementary only replaces these metadata tables with the current graph when the artifacts models run." [dbt artifacts] There is no indication in the knowledge sources that a stale artifact table causes an error or a visible warning in the alert itself — it silently uses whatever is in the table. What about a failed artifact refresh? The knowledge sources do not explicitly cover what happens if the dedicated artifact refresh job fails mid-run (e.g., partial update or table left in an inconsistent state). I cannot confirm this from the available sources. This is worth testing or raising with the Elementary team directly. Your specific cost assessment With an hourly refresh, the practical exposure is: For most stable projects where structure changes infrequently, an hourly refresh is unlikely to cause noticeable degradation in practice. The risk is highest immediately after a deployment that adds new models/tests or changes ownership — in that window, alerts may fire with stale or missing metadata rather than failing visibly. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help., with interactive elements

@kapa.ai would

upload_artifacts_method: append

(or

replace

) avoid the aborted transaction? The abort came from

diff

mode's delete-then-insert. Elementary's own macro comments say append "just insert, and no need to be atomic."

upload_artifacts_method: append / replace and the concurrent transaction error I need to be upfront: the knowledge sources do not mention an

upload_artifacts_method

configuration variable at all, and do not describe an

append

or

replace

mode for artifact uploads, nor do they reference a

diff

mode or the macro comment you're quoting. I cannot confirm from the available sources whether: •

upload_artifacts_method

is a supported or documented configuration option in any version of the Elementary dbt package • Setting it to

append

or

replace

would avoid the BigQuery "transaction aborted due to concurrent update" error • The

diff

mode's delete-then-insert is the specific operation causing the abort (though the sources do confirm artifact tables use a truncate-and-insert / DELETE + INSERT pattern, which is consistent with your hypothesis) [dbt artifacts] What the sources do confirm about the write pattern The artifact tables (

dbt_models

,

dbt_tests

, etc.) use a non-append write strategy — described as truncate-and-insert — which is explicitly why concurrent writes conflict: [Linen thread] > "These metadata tables are 'regular tables' that Elementary updates via

truncate and insert

when those models run." This is consistent with your reading of the macro comments, but the sources only document one supported mitigation:

disable_dbt_artifacts_autoupload: true

combined with a single controlled job. [BQ concurrent runs] Recommendation Since you're reading Elementary's macro source code directly, you likely have more detail than the public documentation covers. I'd recommend: 1. Raising this as a question or feature request on the Elementary GitHub — the team may be able to confirm whether

upload_artifacts_method

is intentionally undocumented or experimental 2. Asking in the Elementary Slack community where core contributors are active This is genuinely outside what I can answer reliably from the available knowledge sources. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.