You have some control over the content and verbosity of Slack alerts sent by Elementary, but there are limitations: ### Customizing Slack Alert Content - Alert Fields: You can specify which fields to include in test alerts using the

alert_fields

property in your model or test

meta

configuration. By default, all fields are shown, but you can limit the alert to only the most relevant fields (e.g., just the test name, column, and status). Example:

yaml     models:       - name: my_model_name         meta:           alert_fields: ["table", "column", "tags", "owners"]

This will reduce the verbosity of each alert by only including the specified fields. Note that this feature is currently supported only for test alerts, not for grouped alerts or other alert types. [See documentation for details](https://docs.elementary-data.com/cloud/guides/alerts-configuration#alerts-distribution). - Grouping Alerts: If you want to further reduce noise, you can group alerts by table, so you receive a single notification per table with all associated issues. However, grouped alerts contain less detailed information for each issue and currently do not support custom field selection. [More info here](https://docs.elementary-data.com/cloud/guides/alerts-configuration#alerts-distribution).

yaml     models:       - name: my_model_name         meta:           slack_group_alerts_by: table

- Suppression Interval: To avoid repeated alerts for the same issue, you can set an

alert_suppression_interval

(in hours) to "snooze" alerts for recurring failures:

yaml     models:       - name: my_model_name         meta:           alert_suppression_interval: 24

### Custom Message Formatting - Custom Message Templates: As of now, you cannot fully customize the Slack message template (e.g., change the structure or wording of the alert) within Elementary. The ability to change the string like "dbt test alert" or to create a fully custom message format is not currently supported, but you can open a feature request for this [as discussed here](https://slack.com/archives/C02CTC89LAX/p1691608483808449). - Workarounds: If you need to send completely custom messages, you would need to build your own integration that consumes Elementary's output (e.g., from the CLI or API), extracts the relevant information, and posts a custom message to Slack. However, this would require additional engineering effort outside of Elementary's built-in capabilities. ### Summary - You can reduce verbosity by specifying

alert_fields

in your configuration. - You can group alerts by table to further reduce noise, but with less detail. - Full customization of the Slack message format is not currently supported. - For advanced customization, you would need to build your own integration to process Elementary's output. For more details and configuration examples, see the [Elementary alert configuration documentation](https://docs.elementary-data.com/cloud/guides/alerts-configuration#alerts-distribution).

You do not have to set

alert_fields

for every individual test. You can set it globally for all tests in a given model by adding it to the model's

meta

block in your

schema.yml

or

dbt_project.yml

. For example:

yaml models:   - name: my_model_name     meta:       alert_fields: ["table", "column", "tags", "owners"]

If you want to apply it to all models in a folder, you can use the

models

key in your

dbt_project.yml

to set it for an entire path:

yaml models:   my_project:     +meta:       alert_fields: ["table", "column", "tags", "owners"]

Elementary prioritizes configuration in this order for tests: 1. Test properties (in the test itself) 2. Tests path configuration under

tests

key in

dbt_project.yml

3. Parent model configuration So, setting it at the model or path level will apply to all tests under that model or path, unless overridden at a more specific level. This allows you to avoid repeating the configuration for every test individually [see documentation](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files).

Yes, you can build your own custom Slack messages by querying the information Elementary stores about test results. Elementary saves test results—including failures—in your data warehouse, specifically in tables like

elementary_test_results

and

test_result_rows

. These tables contain details such as the test name, failing column, tags, owners, and even samples of failed rows. You can query these tables directly to extract the information you need and then use your own script or integration to format and send custom Slack messages. For example, you could write a query to get all failed tests and their relevant metadata, then use that data to construct your own Slack notifications in any format you prefer. Here’s a summary of the relevant points: - elementary_test_results: Contains metadata about each test run, including status, test name, column, tags, owners, etc. - test_result_rows: Stores samples of failed rows (as JSON), which you can include in your custom messages if needed. - You can query these tables from your data warehouse and use the results to build and send your own Slack messages, independent of Elementary’s built-in alerting. This approach is commonly used by teams who want more control over the format or delivery of their alerts, as confirmed in the community discussions and documentation [see example](https://slack.com/archives/C02CTC89LAX/p1741861180336069). If you need more details on the schema or how to extract specific fields, let me know!

Based on the knowledge sources, you should add the

meta

field with the

alert_fields

parameter to the section(s) that correspond to the models or folders where you want the alert configuration to apply. - If you want all models under

tables

(including

monitoring

) to use the same

alert_fields

, you can add the

meta

block under

tables

. - You do not need to add it under

elementary

unless you specifically want to change the alert configuration for the Elementary models themselves (which is usually not necessary, as these are the internal models for Elementary's own processing). Here’s how you might structure it:

yaml models:   tables:     +persist_docs: { "relation": true, "columns": true }     +database: data-drk     +schema: drk-tables     +meta:       alert_fields: ["table", "column", "tags", "owners"]     monitoring:       +database: data-drk       +schema: drk_monitoring   elementary:     +database: data-drk     +schema: elementary     +enabled: "{{ (target.name == 'elementary-prod' or target.name == 'composer-prod') | as_bool }}"

This way, all models under

tables

(and its subfolders like

monitoring

) will inherit the

alert_fields

configuration. You do not need to duplicate the

meta

block under both

tables

and

elementary

unless you want different alert settings for each. This approach is supported by the configuration precedence and inheritance described in the documentation: model path configuration under the

models

key in

dbt_project.yml

applies to all models in that path, unless overridden at a more specific level [see documentation](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files).

Yes, you can add

slack_group_alerts_by

and

owner

(as well as

alert_fields

) in the

+meta

block at the folder level in your

dbt_project.yml

, just as you showed:

yaml models:   tables:     +persist_docs: { "relation": true, "columns": true }     +database: data-drk     +schema: drk-tables     +meta:       alert_fields: ["table", "column", "tags", "owners"]       slack_group_alerts_by: table       owner: "@captain-data"     monitoring:       +database: data-drk       +schema: drk_monitoring   elementary:     +database: data-drk     +schema: elementary     +enabled: "{{ (target.name == 'elementary-prod' or target.name == 'composer-prod') | as_bool }}"

With this configuration, all models (and thus all tests defined on those models) under the

tables

path will inherit these

meta

properties—unless they are overridden at a more specific level (e.g., directly on a model or test). This means every test under your

schema.yml

and

sources.yml

files for models in the

tables

folder will have the specified

owner

,

alert_fields

, and

slack_group_alerts_by

settings applied by default. This is supported by Elementary’s configuration precedence, which states that model path configuration under the

models

key in

dbt_project.yml

applies to all models in that path, unless overridden at a more specific level. The same applies for the

meta

fields you listed, including

owner

and

slack_group_alerts_by

[see documentation](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files). So your understanding is correct!

Short answer: run a dbt command so Elementary can pick up the new config, and make sure you put it in the right place. - Elementary ingests meta/config from your YMLs via dbt’s on-run-end hooks, so after changing dbt_project.yml you need to run a dbt command to update Elementary’s tables (e.g., dbt run --select dbt_models, or any dbt invocation) before running edr monitor (the CLI reads from those tables) ([How config is picked up](https://slack.com/archives/C02CTC89LAX/p1682073866770489); [recommended flow](https://slack.com/archives/C02CTC89LAX/p1686842159294479)). - Placement matters: - For tests, config precedence is: test properties > tests path in dbt_project.yml > parent model config. If you want a default for all tests under a path, putting it under tests: <path>: +meta is valid, but parent model config often overrides only when test-level isn’t set ([config precedence](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alert-properties-in-yml-files)). - If your goal is to affect all tests on models in a folder, many users place meta under models: <path>: +meta so it flows to tests via the parent model. Misplacing “global” config under tests vs models caused unexpected overrides in a prior thread ([example and fix](https://slack.com/archives/C02CTC89LAX/p1673893162838399)). - After updating dbt_project.yml: 1) Run dbt (e.g., dbt run --select dbt_models or simply dbt test/build) to refresh Elementary’s dbt_models table/meta. 2) Then run edr monitor. If tables were missing/old, run dbt run -s elementary to (re)create Elementary models/tables, then dbt test, then edr monitor ([flow and when to run -s elementary](https://slack.com/archives/C02CTC89LAX/p1686842159294479)). - Tip: Verify your config landed by querying the meta column:

sql   select name, meta   from <elementary_schema>.dbt_models

If it’s not there, the issue is with config location or dbt not having run since the change ([verification step](https://slack.com/archives/C02CTC89LAX/p1696248890616769), [same approach](https://slack.com/archives/C02CTC89LAX/p1682073866770489)). - Finally, alert_fields only affects test alerts and must be picked up from meta. Grouped alerts by table include less detail and don’t use per-field selection ([alert_fields scope](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-distribution)). If after these steps it still doesn’t change, please share whether the meta shows up in dbt_models and where the config lives (tests vs models) so we can pinpoint precedence.