https://linen.dev logo
Join Slack
Powered by
<@U088WCP3B4P> I have this .yml file in dbt: vers...
# ask-elementary-ai
y
@kapa.ai I have this .yml file in dbt: version: 2 sources: - name: staging_back_office_jl_es description: PayFit's Back Office JetLang variables data for Spain ingested by PayLoad project. schema: staging_back_office_jl_es database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" tables: - name: companies_jl_variables description: Back office's companies JL variables for Spain, refreshed each day at 0am UTC. - name: employees_jl_variables description: Back office's employees JL variables for Spain, refreshed each day at 0am UTC. config: freshness: warn_after: period: hour count: 24 There's a freshness test in it. How to set up a slack channel to this test?
k
A message from kapa.ai
You can route Elementary’s freshness alerts to a specific Slack channel by using 
meta
on the source/table, not inside the 
freshness:
block itself. Based on the docs, alert properties (including 
channel
) are read from 
meta
on models/sources/tests, with a defined priority order. [[Alert props](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] For a source table freshness alert, configure it like this:
Copy code
yml version: 2  sources:   - name: staging_back_office_jl_es     description: PayFit's Back Office JetLang variables data for Spain ingested by PayLoad project.     schema: staging_back_office_jl_es     database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}"      tables:       - name: companies_jl_variables         description: Back office's companies JL variables for Spain, refreshed each day at 0am UTC.         meta:           channel: data_ops_slack_channel   # <- Elementary Slack channel for alerts         freshness:           warn_after:             period: hour             count: 24        - name: employees_jl_variables         description: Back office's employees JL variables for Spain, refreshed each day at 0am UTC.         meta:           channel: data_ops_slack_channel         freshness:           warn_after:             period: hour             count: 24
A few important notes from the knowledge sources: - The 
channel
key is part of 
meta
and is how you define a custom Slack channel per resource. [[Alert props](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] - Elementary will still need a default Slack destination configured via the CLI/config (
--slack-token
+ 
--slack-channel-name
or webhook) for alerts to work at all. [[Slack setup](https://docs.elementary-data.com/oss/guides/alerts/send-slack-alerts); [Slack config](https://docs.elementary-data.com/oss/deployment-and-configuration/slack#page-title)] - There are known dbt quirks around 
meta
precedence on sources (project-level vs source/table), so if you also configure 
meta
for sources in 
dbt_project.yml
, be aware that project-level may override table-level in some dbt versions. [[Source meta bug](https://elementary-community.slack.com/archives/C02CTC89LAX/p1680099515160789?thread_ts=1680099515.160789&amp;cid=C02CTC89LAX)] If you share how you currently run Elementary (CLI command + Slack config), I can help you adjust that part as well.
y
can i just put the meta with the config at the and of the file so that it's set up for all tables,
@kapa.ai can i just put the meta with the config at the and of the file so that it's set up for all tables,
k
A message from kapa.ai
Yes, you can set this once for all tables, but it needs to be done using dbt’s standard 
meta
inheritance, not under 
config:
in the source file. For sources, global meta is usually defined in 
dbt_project.yml
, and then inherited by all matching tables. For example, to send all source-related alerts to the same Slack channel:
Copy code
yml # dbt_project.yml sources:   staging_back_office_jl_es:     +meta:       alerts_config:         channel: data_ops_slack_channel
Then your source file can stay simple:
Copy code
yml version: 2  sources:   - name: staging_back_office_jl_es     schema: staging_back_office_jl_es     database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}"      tables:       - name: companies_jl_variables         freshness:           warn_after:             period: hour             count: 24        - name: employees_jl_variables         freshness:           warn_after:             period: hour             count: 24
Key points from the knowledge sources: - Alert properties like 
channel
are read from 
meta.alerts_config
on the resource (model/source/table/test). [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-distribution)] - You can configure alert settings for sources in 
dbt_project.yml
using 
sources: ... +meta: alerts_config: ...
. [[Source alerts config](https://elementary-community.slack.com/archives/C02CTC89LAX/p1680099515160789?thread_ts=1680099515.160789&amp;cid=C02CTC89LAX)] - There is a known dbt-core bug where project-level 
meta
on sources can override table-level 
meta
unexpectedly, so if you also set 
meta
in the source 
.yml
, be aware of that precedence issue. [[dbt meta bug](https://github.com/elementary-data/elementary/issues/2007)] What you can’t do (per the docs and Slack threads) is put 
meta
directly under a 
config:
block at the bottom of the same source file and expect it to apply to all tables; global config for sources is handled via 
dbt_project.yml
, not a 
config:
section inside the source 
.yml
.
y
@kapa.ai but i can add other arguments in the meta directly in the config such as owner, domain, etc. but i can't add channel? why?
k
A message from kapa.ai
You’ve run into an inconsistency that comes from two different layers: 1. dbt behavior (what gets parsed into 
meta
) 2. Elementary behavior (how it interprets 
meta
for alerts) From the knowledge sources: - Elementary reads alert properties (including 
owner
, 
subscribers
, 
tags
, 
channel
, etc.) from 
meta
on models/sources/tests, with a clear priority order. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] - The examples for models/tests show 
meta
keys like 
owner
, 
subscribers
, 
description
, 
tags
, 
channel
, 
alert_suppression_interval
, 
slack_group_alerts_by
, 
alert_fields
all living side‑by‑side. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files); [Alerts distribution](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-distribution)] - There are known quirks/bugs in dbt around how 
meta
is applied for sources and for tests: - For sources, project‑level 
meta
can override source/table‑level 
meta
in unexpected ways. [[Source meta bug](https://github.com/elementary-data/elementary/issues/2007); [Slack thread](https://elementary-community.slack.com/archives/C02CTC89LAX/p1680099515160789?thread_ts=1680099515.160789&amp;cid=C02CTC89LAX)] - For tests, Jinja in 
meta
under a test is not parsed the same way as under a model, which is why support suggests moving channel config to the model/table level as a workaround. [[Jinja under test meta](https://elementary-community.slack.com/archives/C02CTC89LAX/p1674376762559239?thread_ts=1674376762.559239&amp;cid=C02CTC89LAX)] The knowledge sources do not explicitly say that 
channel
is treated differently from `owner`/`domain` inside 
meta
on a source, nor do they document a restriction that would allow some keys (owner, domain) but not 
channel
. On the contrary, they show 
channel
as just another supported 
meta
key for alerts. [[Alerts distribution](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-distribution)] So, based on the docs and Slack threads: - Elementary intends to support 
channel
in 
meta
the same way as 
owner
, 
tags
, etc. - If `owner`/`domain` work for you in a given 
meta
location but 
channel
does not, that’s likely due to: - dbt’s handling/merging of 
meta
for sources (project vs source vs table), or - how Elementary currently reads 
meta
for source freshness specifically (vs models/tests), which is not fully documented in the provided sources. The knowledge sources do not contain enough detail to pinpoint exactly why 
channel
is not being picked up in your specific placement while other keys are, beyond these known meta/precedence quirks. I can’t confidently say more without going beyond the docs and Slack threads you provided. Practical workaround from the sources Given these limitations, the patterns that are documented to work are: - Put alert‑related 
meta
(including 
channel
) at the model/table level, not nested under the test/freshness block. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] - For sources, prefer configuring shared 
meta
in 
dbt_project.yml
under 
sources: ... +meta: ...
, being aware of the precedence bug. [[Source alerts config](https://elementary-community.slack.com/archives/C02CTC89LAX/p1680099515160789?thread_ts=1680099515.160789&amp;cid=C02CTC89LAX)] If you can share the exact snippet where `owner`/`domain` work but 
channel
doesn’t, that would help map it more directly to one of the documented dbt/Elementary quirks.
y
what's the different between adding channel under meta which is under argument, and just adding channel under meta? @kapa.ai
k
A message from kapa.ai
The knowledge sources don’t explicitly describe a semantic difference between:
Copy code
yml meta:   channel: my_channel
and:
Copy code
yml meta:   some_argument: foo   channel: my_channel
As far as Elementary is concerned, 
channel
is just one of several supported alert properties that can live directly under 
meta
(alongside 
owner
, 
subscribers
, 
tags
, etc.). [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] What does matter in the docs is: 1. Where 
meta
is attached (model, source, table, test, or project-level in 
dbt_project.yml
) and the precedence rules: - For models/sources: model config block → model properties → 
dbt_project.yml
path config. - For tests: test properties → 
tests
in 
dbt_project.yml
→ parent model config. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] 2. How dbt handles 
meta
for sources/tests, which can cause overrides or unparsed Jinja, independent of which keys you put under 
meta
. [[Source meta bug](https://github.com/elementary-data/elementary/issues/2007); [Jinja under test meta](https://elementary-community.slack.com/archives/C02CTC89LAX/p1674376762559239?thread_ts=1674376762.559239&amp;cid=C02CTC89LAX)] The sources do not document any special rule like “`channel` only works if 
meta
has no other arguments” or “`channel` behaves differently from 
owner
when combined under 
meta
.” So, based on the available docs: - Elementary expects 
channel
to work the same way as other alert keys when placed directly under 
meta
. - Any difference you’re seeing is more likely due to where that 
meta
block is attached (and dbt’s precedence/bugs there), not whether 
channel
is alone or alongside other keys under 
meta
.
y
i mean the different between: argument: meta: channel: and meta: channel:
@kapa.ai i mean the different between: argument: meta: channel: and meta: channel:
k
A message from kapa.ai
The knowledge sources don’t mention any special meaning for an 
argument:
key, and they only show 
meta
attached directly to the dbt resource (model/source/test), not nested under another arbitrary key. All documented examples look like:
Copy code
yml models:   - name: my_model_name     config:       meta:         channel: data_ops
or:
Copy code
yml models:   - name: my_model_name     meta:       channel: data_ops
and for tests:
Copy code
yml data_tests:   - not_null:       config:         meta:           description: "This is the test description"
with 
channel
listed as one of the supported keys directly under 
meta
. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files); [Alerts distribution](https://docs.elementary-data.com/cloud/guides/alerts-configuration#alerts-distribution)] There is no example or explanation of a structure like:
Copy code
yml argument:   meta:     channel: ...
So, based on the docs: - 
meta: channel: ...
should be attached directly to the resource (or under 
config:
for models/tests, or via 
+meta:
in 
dbt_project.yml
). - An extra wrapper key like 
argument:
is not documented and may simply not be read by dbt/Elementary at all. Because 
argument:
is not described anywhere in the provided sources, I can’t say it has any supported effect for Elementary alerts.
y
@kapa.ai In below yml file, if i set up the config at the end of the file like that, will the channel name be applied to only the freshenss test above it or to all tests in the file including the volume_anomalies test? version: 2 sources: - name: staging_zuora description: | ## Technical description Zuora's data ingested by Airbyte (https://docs.airbyte.com/integrations/sources/zuora), all tables are freshed each day at 0am UTC. ## Functional description Functional description taken from [here](https://www.notion.so/payfitapp/Zuora-data-model-96312146fb7d4568a66bdccc4235cb87) database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" tables: - name: account description: '{{ doc("src_zuora__account") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 15 drop_failure_percent_threshold: 15 - name: contact description: '{{ doc("src_zuora__contact") }}' columns: - name: workemail config: meta: database_tags: data_classification: "level_1" - name: address1 config: meta: database_tags: data_classification: "level_1" - name: address2 config: meta: database_tags: data_classification: "level_1" - name: subscription description: '{{ doc("src_zuora__subscription") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 columns: - name: subscriptionstartdate data_tests: - not_null - name: rateplan description: '{{ doc("src_zuora__rateplan") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: rateplancharge description: '{{ doc("src_zuora__rateplancharge") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 columns: - name: subscriptionid data_tests: - not_null - name: rateplanchargetier description: '{{ doc("src_zuora__rateplanchargetier") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: productrateplan description: '{{ doc("src_zuora__productrateplan") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: productrateplancharge description: '{{ doc("src_zuora__productrateplancharge") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: usage description: '{{ doc("src_zuora__usage") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: invoice description: '{{ doc("src_zuora__invoice") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: invoiceitem description: '{{ doc("src_zuora__invoiceitem") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 10 drop_failure_percent_threshold: 10 - name: creditmemo description: '{{ doc("src_zuora__creditmemo") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: creditmemoitem description: '{{ doc("src_zuora__creditmemoitem") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: debitmemo description: '{{ doc("src_zuora__debitmemo") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: debitmemoitem description: '{{ doc("src_zuora__debitmemoitem") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: payment description: '{{ doc("src_zuora__payment") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: paymentapplication description: '{{ doc("src_zuora__paymentapplication") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: creditmemoapplication description: '{{ doc("src_zuora__creditmemoapplication") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: paymentmethod description: '{{ doc("src_zuora__paymentmethod") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: orders description: '{{ doc("src_zuora__orders") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: orderaction description: '{{ doc("src_zuora__orderaction") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: orderactionrateplan description: '{{ doc("src_zuora__orderactionrateplan") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 5 drop_failure_percent_threshold: 5 - name: productdiscountapplydetail description: '{{ doc("src_zuora__productdiscountapplydetail") }}' data_tests: - elementary.volume_anomalies: arguments: detection_period: period: day count: 1 ignore_small_changes: spike_failure_percent_threshold: 20 drop_failure_percent_threshold: 20 config: freshness: error_after: period: hour count: 24 meta: channel: data-bugs
k
A message from kapa.ai
The knowledge sources don’t describe 
config:
blocks on 
sources:
in detail, so I can’t say with full certainty how dbt will treat that exact pattern. However, based on what is documented about how Elementary reads alert configuration from 
meta
, the 
channel
you set under 
meta
at the bottom will apply to all alerts for that source, not just the freshness test. Elementary looks for alert properties (including 
channel
) on the resource’s 
meta
, and the more specific level overrides the less specific one. For models/sources, it prioritizes: 1. Model (or source/table) config block 2. Model (or source/table) properties 3. Path configuration in 
dbt_project.yml
[[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] And for tests, it prioritizes: 1. Test properties 2. Tests path config in 
dbt_project.yml
3. Parent model configuration [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] Because your 
meta.channel
is defined once at the source level:
Copy code
yml sources:   - name: staging_zuora     ...     config:       freshness:         ...       meta:         channel: data-bugs
Elementary will see 
channel: data-bugs
as the default channel for all alerts under that source (freshness + all 
elementary.volume_anomalies
tests), unless you override 
channel
more specifically on a particular test or table. So in practice, with the config you showed, 
data-bugs
will be used for: - The source freshness alert on 
staging_zuora
- All 
elementary.volume_anomalies
tests defined under its tables If you want a different channel for some tests, you’d need to set 
meta.channel
at the test (or table) level for those specific tests, which will override the source-level setting. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)]
y
@kapa.ai in below yml file: version: 2 sources: - name: staging_facebook_ads_gb description: > Facebook marketing data for GB ingested by Airbyte (https://docs.airbyte.com/integrations/sources/facebook-marketing), all tables are freshed each day at 0am UTC database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" tables: - name: ads_insights description: Facebook Marketing's ads insights data. Updated incrementaly each day at 0am UTC (based on fields date_start, account_id and ad_id). config: freshness: warn_after: period: hour count: 24 meta: channel: data-bugs - name: _archive_staging_facebook_ads_de description: > Facebook marketing data for DE ingested by Airbyte (https://docs.airbyte.com/integrations/sources/facebook-marketing), all tables are freshed each day at 0am UTC database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" schema: _archive_staging_facebook_ads_de tables: - name: ads_insights description: Facebook Marketing's ads insights data. Updated incrementaly each day at 0am UTC (based on fields date_start, account_id and ad_id). - name: staging_facebook_ads_fr description: > Facebook marketing data for FR ingested by Airbyte (https://docs.airbyte.com/integrations/sources/facebook-marketing), all tables are freshed each day at 0am UTC. database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" tables: - name: ads_insights description: Facebook Marketing's ads insights data. Updated incrementaly each day at 0am UTC (based on fields date_start, account_id and ad_id). config: freshness: warn_after: period: hour count: 26 meta: channel: data-bugs - name: staging_facebook_ads_es description: > Facebook marketing data for ES ingested by Airbyte (https://docs.airbyte.com/integrations/sources/facebook-marketing), all tables are freshed each day at 0am UTC database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" tables: - name: ads_insights description: Facebook Marketing's ads insights data. Updated incrementaly each day at 0am UTC (based on fields date_start, account_id and ad_id). this test: config: freshness: warn_after: period: hour count: 24 meta: channel: data-bugs will the test be applied only to the table ads_insights or to all tables?
k
A message from kapa.ai
The knowledge sources don’t explicitly document 
config:
blocks on 
sources:
in this exact shape, so I can’t be 100% certain how dbt will interpret that snippet. However, based on how Elementary reads alert configuration from 
meta
, the 
meta.channel
you set in that 
config
block is **not scoped to a single table**; it’s attached to the source (
staging_facebook_ads_gb
, 
staging_facebook_ads_fr
, etc.), and will apply to all alerts under that source unless overridden more specifically. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] In your example:
Copy code
yml sources:   - name: staging_facebook_ads_gb     ...     tables:       - name: ads_insights         ...      config:       freshness:         warn_after:           period: hour           count: 24       meta:         channel: data-bugs
That 
config
block is at the source level, not under the 
tables:
entry. So: - The freshness config there is a source-level freshness (for that source). - The 
meta.channel: data-bugs
is a source-level alert config. - Any Elementary alerts for that source (e.g., source freshness, and any tests defined under its tables) will inherit 
channel: data-bugs
, unless you define a more specific 
meta.channel
on a particular table or test, which would override it. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] So, to your question: > will the test be applied only to the table 
ads_insights
or to all tables? Given the position of the 
config
block, it is not scoped only to that single 
ads_insights
table; it is scoped to the whole 
staging_facebook_ads_gb
source. Any additional tables you add under that same source would also inherit that source-level freshness and 
meta.channel
, unless you override them at the table/test level.
y
@kapa.ai version: 2 sources: - name: staging_jira description: Jira's data ingested by Airbyte (https://docs.airbyte.com/integrations/sources/jira) all tables are updated incrementally or refreshed each day at 0am UTC. database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" tables: - name: full_refresh_issues description: '{{ doc("src_jira__issues") }}' config: freshness: warn_after: period: day count: 7 error_after: period: day count: 8 in this file, can i set different channels for warn and error?
k
A message from kapa.ai
The knowledge sources indicate that Elementary supports only one Slack channel per alert, taken from the resource’s 
meta
(e.g. 
meta.channel
or 
meta.alerts_config.channel
), and they do not describe any way to choose a different channel based on whether the outcome is 
warn
vs 
error
for the same test or freshness check. [[Alert properties](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)] Multiple Slack threads explicitly say that routing warnings and errors to different channels requires separate 
edr monitor
runs with filters, not configuration inside the test itself: - Use selectors like 
statuses:warn
and 
statuses:error
with different 
--slack-channel-name
values. [[Statuses select](https://elementary-community.slack.com/archives/C02CTC89LAX/p1700589524214199?thread_ts=1700589524.214199&amp;cid=C02CTC89LAX); [Severity workaround](https://elementary-community.slack.com/archives/C02CTC89LAX/p1687388986079909?thread_ts=1687388986.079909&amp;cid=C02CTC89LAX)] Example pattern from the sources:
Copy code
bash edr monitor --slack-channel-name warn-channel  --select 'statuses:warn' edr monitor --slack-channel-name error-channel --select 'statuses:fail'
So, for your 
staging_jira
source freshness:
Copy code
yml sources:   - name: staging_jira     ...     tables:       - name: full_refresh_issues         ...         config:           freshness:             warn_after: ...             error_after: ...         meta:           channel: data-bugs
- You can set one 
meta.channel
(or 
meta.alerts_config.channel
) for that freshness alert. - You cannot configure “warns go to channel A, errors go to channel B” for that same freshness test purely in YAML; the documented way is to split by status in 
edr monitor
runs.
y
@kapa.ai so you mean if i set up a channel in the yml for both warning and error, and then i specify different channels in the 
edr monitor
 like this :
Copy code
edr monitor --slack-channel-name warn-channel  --select 'statuses:warn'
edr monitor --slack-channel-name error-channel --select 'statuses:fail'
it will override the channels that i defined in the yml file?
k
A message from kapa.ai
No — the CLI channels won’t override channels you’ve explicitly set in YAML. From the docs and Slack threads: - 
--slack-channel-name
is the default channel, used only when no custom channel is defined in 
meta
 for that alert. [[Send Slack alerts](https://docs.elementary-data.com/oss/guides/alerts/send-slack-alerts#execute-the-cli); [Custom channel explainer](https://elementary-community.slack.com/archives/C02CTC89LAX/p1693810648674049?thread_ts=1693810648.674049&amp;cid=C02CTC89LAX)] - Custom channels defined in YAML (e.g. 
meta.channel
/ 
meta.alerts_config.channel
) take precedence over the CLI default. [[Alerts configuration](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#custom-channel); [Precedence order](https://elementary-community.slack.com/archives/C02CTC89LAX/p1681400928815089?thread_ts=1681400928.815089&amp;cid=C02CTC89LAX)] So in your scenario: - If a test/freshness has a channel set in YAML, that alert will still go to the YAML‑defined channel, even when you run:
Copy code
bash   edr monitor --slack-channel-name warn-channel  --select 'statuses:warn'   edr monitor --slack-channel-name error-channel --select 'statuses:fail'
- Those two 
edr monitor
commands only control alerts that don’t already have a custom channel in their 
meta
. If you want the CLI channels to be used, you’d need to remove the channel from YAML for those tests, or use selectors so that the runs only pick up tests without a custom channel.
y
@kapa.ai In below file, i want to change the warn_after into 72 hours for the table salary_payment_information and keep the 24 hours for the other 2 tables, how to do it: version: 2 sources: - name: staging_payments description: > It contains data related to the new Payments v2 API. database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}" tables: - name: payment description: '{{ doc("src_payments__payment") }}' - name: salary_payment_information description: '{{ doc("src_payments__salary_payment_information") }}' - name: transaction description: '{{ doc("src_payments__transaction") }}' config: freshness: warn_after: period: hour count: 24 meta: channel: data-bugs
k
A message from kapa.ai
You can override the source‑level freshness on a specific table by defining a 
freshness
block on that table. The table‑level config will take precedence over the source‑level config. [[dbt sources table freshness](https://docs.elementary-data.com/data-tests/dbt/package-models#dbt-sources)] In your case:
Copy code
yml version: 2  sources:   - name: staging_payments     description: >       It contains data related to the new Payments v2 API.     database: "{{ env_var('SNOWFLAKE_RAW_DATABASE', 'RAW_PROD') }}"      tables:       - name: payment         description: '{{ doc("src_payments__payment") }}'        - name: salary_payment_information         description: '{{ doc("src_payments__salary_payment_information") }}'         freshness:           warn_after:             period: hour             count: 72    # 72 hours for this table only        - name: transaction         description: '{{ doc("src_payments__transaction") }}'      config:       freshness:         warn_after:           period: hour           count: 24      # default 24 hours for other tables       meta:         channel: data-bugs
- 
payment
and 
transaction
will use the source‑level 
warn_after: 24 hours
. - 
salary_payment_information
will use its own 
warn_after: 72 hours
.
y
@kapa.ai can i set up multiple channels for a same test?
k
A message from kapa.ai
No, you can’t configure a single Elementary test to send to multiple Slack channels at the same time. Several Slack threads explicitly state this is not supported: - “At the moment we don’t support this option” when asked about sending one failing test to 2 channels. [[Two channels](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684821961495539?thread_ts=1684821961.495539&amp;cid=C02CTC89LAX)] - “Can I send 1 slack alert for a failing test to two different slack channels at the same time? … Not at the moment I’m afraid.” [[One alert two channels](https://elementary-community.slack.com/archives/C02CTC89LAX/p1698135969472479?thread_ts=1698135969.472479&amp;cid=C02CTC89LAX)] - Another user asking for multiple channels per test was told “this is currently not supported… a github issue is a great idea!” [[Multiple channels request](https://elementary-community.slack.com/archives/C02CTC89LAX/p1706802672453849?thread_ts=1706802672.453849&amp;cid=C02CTC89LAX)] So today each alert is sent to exactly one channel (either from 
meta.channel
/ alert config, or the default CLI channel).
47 Views
Open in Slack
PreviousNext
Powered by