Slackbot
03/10/2026, 3:13 PMkapa.ai
03/10/2026, 3:14 PMdbt_project.yml to control Elementary's enablement:
vars:
enable_elementary: false
models:
elementary:
+schema: "elementary"
+enabled: "{{ var('enable_elementary', false) }}"
With this setup:
⢠Elementary is off by default ā a plain dbt run or dbt build won't run Elementary models.
⢠Enable it on demand by passing the var at the CLI:
dbt run --vars '{"enable_elementary": true}'
[deactivate by default]
-------------------------
Environment-based toggle (alternative)
If you want Elementary to be automatically enabled in specific environments (e.g., prod) without needing to pass a var each time:
models:
elementary:
+schema: "elementary"
+enabled: "{{ target.name in ['prod', 'analytics'] }}"
[disable per env]
-------------------------
Important: Don't forget the hooks
The +enabled config disables the models, but the on-run-end hooks are controlled separately. To fully disable Elementary (models + hooks), also add these vars:
vars:
disable_run_results: "{{ target.name != 'prod' }}"
disable_tests_results: "{{ target.name != 'prod' }}"
disable_dbt_artifacts_autoupload: "{{ target.name != 'prod' }}"
disable_dbt_invocation_autoupload: "{{ target.name != 'prod' }}"
[disable hooks] š 0 button š 0 button ā¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.Senmi Rai
04/01/2026, 7:18 PMkapa.ai
04/01/2026, 7:18 PMdbt_models, dbt_tests, and dbt_sources. Your test results and run results will still be collected, so alerts based on test failures will continue to work. However, metadata shown in alerts (e.g., model names, owners, tags) may become stale if your project structure changes. [on-run-end hooks] Disabling result uploads (disable_run_results, disable_tests_results) If you also disable these, test results and run results won't be uploaded, which means Elementary will have no data to generate alerts from ā your Slack alerts will stop working. [disable hooks] Elementary's own recommendation > "We strongly recommend not to disable the hooks for environments you want to monitor using Elementary." [on-run-end hooks] Recommended setup for Slack alerts If you want alerts to work while still controlling artifact uploads, use this pattern:
vars:
disable_dbt_artifacts_autoupload: true # disables metadata uploads (safe for alerts)
disable_run_results: false # keep this enabled for alerts
disable_tests_results: false # keep this enabled for alerts
disable_dbt_invocation_autoupload: false # keep this enabled for alerts
Then manually refresh metadata when your project changes:
dbt run --select elementary.edr.dbt_artifacts
This way, your Slack alerts remain fully functional while you control when metadata is updated. [disable hooks] š 0 button š 0 button ā¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.Senmi Rai
04/01/2026, 7:20 PMkapa.ai
04/01/2026, 7:20 PMdisable_dbt_artifacts_autoupload: true will partially affect report generation, but not completely break it.
Here's what happens:
What still works:
⢠Runtime tables (dbt_run_results, elementary_test_results, dbt_invocations) are still populated by the on-run-end hooks, so test outcomes, model run times, and execution history will still appear in reports. [on-run-end hooks]
What may be affected:
⢠Reports rely on joining runtime results with metadata from artifact tables (e.g., dbt_tests, dbt_models). If those metadata tables are stale or outdated, tests and models may be misrepresented or missing from reports. [dbt artifacts]
⢠New models, tests, or sources added to your project won't show up in reports until you manually refresh the artifacts.
⢠Config changes (owners, tags, severity, etc.) won't be reflected in the report context.
The fix:
Run the following whenever your project structure changes (e.g., after a deployment):
dbt run --select elementary.edr.dbt_artifacts
This keeps metadata current without needing to upload it on every single run. [reduce on-run-end time]
In short: reports will still show runtime data, but the project metadata context (model names, test configs, owners, etc.) may become stale if you don't manually refresh artifacts after project changes. š 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
04/01/2026, 7:22 PMpackages.yml and the CLI (edr) is installed in your Cloud Run environment:
pip install elementary-data
pip install 'elementary-data[bigquery]'
[CLI install] 2. Create a Slack App 1. Go to the Slack app creation page and create a new app from scratch.
2. Under "OAuth & Permissions", add these Bot Token Scopes:
⦠channels:join, channels:read, chat:write, files:write, users:read, users:read.email, groups:read
1. Click "Install to Workspace" to generate a Slack Bot Token.
[Slack setup] 3. Configure Elementary to Use Slack You can pass credentials via CLI or a config file. For Cloud Run, environment variables are the cleanest approach:
Via CLI (in your Airflow BashOperator or Cloud Run command):
edr monitor --slack-token <your_slack_token> --slack-channel-name <channel_name>
Or via `~/.edr/config.yml`:
slack:
token: <your_slack_token>
channel_name: <slack_channel_to_post_at>
group_alerts_by: table # or alert
[send Slack alerts] 4. Add edr monitor to Your Airflow DAG After your dbt run and test steps, add an edr monitor step. A typical Airflow DAG pattern:
from airflow.operators.bash_operator import BashOperator
dbt_run = BashOperator(
task_id='dbt_run',
bash_command="dbt run --profiles-dir ..."
)
dbt_test = BashOperator(
task_id='dbt_test',
bash_command="dbt test --profiles-dir ..."
)
edr_monitor = BashOperator(
task_id='elementary_monitor',
bash_command="edr monitor --slack-token $SLACK_TOKEN --slack-channel-name $EDR_SLACK_CHANNEL"
)
dbt_run >> dbt_test >> edr_monitor
[Airflow scheduling] 5. Keep Your Current Artifact Setup Since you already have disable_dbt_artifacts_autoupload: true and a separate job running dbt run --select elementary on deploy, your alerts will work fine ā test results and run results are still collected by the hooks, which is what edr monitor uses to generate alerts. [on-run-end hooks]
> Note: By default, Elementary sends alerts for failures only (not warnings). To also receive warning alerts, make sure disable_warn_alerts is not set to true in your dbt_project.yml. [disable_warn_alerts] š 0 button š 0 button ā¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.Senmi Rai
04/01/2026, 7:30 PMkapa.ai
04/01/2026, 7:30 PMelementary-data to your requirements.txt and running pip install -r requirements.txt will install the Elementary CLI (edr) along with the Python package. They are the same package. [CLI install]
For BigQuery, you'd want both lines in your `requirements.txt`:
elementary-data
elementary-data[bigquery]
After installation, you can verify it worked by running:
edr --help
One common gotcha: On macOS, the edr executable may be installed in a location not on your PATH by default. If you get command not found: edr after installing, check the warning in your terminal output ā it will tell you the path to add. [troubleshooting]
In containerized environments (like your Cloud Run setup), this is usually not an issue as long as the package is installed in the same Python environment that executes the commands. š 0 button š 0 button ā¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.Senmi Rai
04/01/2026, 7:34 PMkapa.ai
04/01/2026, 7:34 PMpip install approach applies, but there are a few container-specific things to be aware of. Installing in a Docker Image Add to your `requirements.txt`:
elementary-data
elementary-data[bigquery]
Then in your Dockerfile:
RUN pip install -U pip
RUN pip install -r requirements.txt
This will install the edr CLI inside the container. [CLI install] Common Docker-Specific Gotchas 1. edr not found in PATH
After pip install, the edr executable may not be on the container's PATH. Add this to your Dockerfile:
ENV PATH="/usr/local/bin:/usr/local/lib/python3.11/site-packages:/usr/local/lib/python3.11/bin:${PATH}"
Adjust the Python version to match what's in your image. [PATH issue]
2. Permission errors when edr runs
Elementary tries to install its internal dbt packages at runtime. In a container with a non-root user, this can cause PermissionError. Pre-install them during the image build as root:
RUN dbt deps --project-dir $(python -c "import os; from elementary.monitor import dbt_project_utils; print(os.path.dirname(os.path.realpath(dbt_project_utils.__file__)))")/dbt_project
[permission fix]
3. Alternative: Use the official Elementary Docker image
If you'd rather not manage the installation yourself, Elementary publishes a ready-to-use Docker image:
docker pull ghcr.io/elementary-data/elementary:latest
The ENTRYPOINT is already set to edr, so you can run commands directly. [Docker docs] š 0 button š 0 button ā¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.Senmi Rai
04/01/2026, 7:39 PMkapa.ai
04/01/2026, 7:39 PMpip install elementary-data
# Then add your warehouse adapter:
pip install 'elementary-data[bigquery]'
pip install 'elementary-data[snowflake]'
pip install 'elementary-data[redshift]'
pip install 'elementary-data[databricks]'
pip install 'elementary-data[athena]'
pip install 'elementary-data[trino]'
pip install 'elementary-data[clickhouse]'
pip install 'elementary-data[duckdb]'
pip install 'elementary-data[dremio]'
pip install 'elementary-data[spark]'
pip install 'elementary-data[vertica]'
# Postgres doesn't require an adapter step
[CLI install] 2. Install from Source git clone https://github.com/elementary-data/elementary
pip install ./elementary
[CLI install] 3. Docker Image Elementary provides an official pre-built Docker image with edr, adapters, and pinned dependencies already included:
docker pull ghcr.io/elementary-data/elementary:latest
# Or a specific version:
docker pull ghcr.io/elementary-data/elementary:v0.20.0
[Docker docs] Deployment / Orchestration Methods Once installed, the CLI can be run via: [Elementary in production]
⢠Airflow ā using a BashOperator after dbt tasks
⢠GitHub Actions ā using the dedicated elementary-data/run-elementary-action
⢠GitLab CI ā using the Docker image in a CI pipeline
⢠Prefect
⢠Meltano ā via a custom Elementary integration
⢠Cron
⢠Elementary Cloud ā fully managed option
> Note: uv is not a supported installation method ā if you install via uv, the CLI commands may not register correctly. [uv issue] š 0 button š 0 button ā¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.Senmi Rai
04/02/2026, 4:36 PMkapa.ai
04/02/2026, 4:36 PMdbt_invocations, then pull model execution times:
SELECT
name,
status,
execution_time,
execute_started_at,
execute_completed_at
FROM elementary.dbt_run_results
WHERE invocation_id = '<your_invocation_id>'
AND resource_type = 'model'
ORDER BY execution_time DESC;
[dbt run results] 2. Rank Tests by Execution Time in a Specific Schema Useful for identifying slow tests:
WITH _execution_time AS (
SELECT
model_execution_id,
unique_id,
execution_time
FROM dbt_run_results
),
_test_results AS (
SELECT
test_execution_id,
test_unique_id,
schema_name
FROM elementary_test_results
WHERE schema_name = '<SCHEMA_OF_INTEREST>'
)
SELECT
test_unique_id,
MAX(execution_time) AS max_execution_time
FROM _test_results
LEFT JOIN _execution_time ON model_execution_id = test_execution_id
GROUP BY test_unique_id
ORDER BY max_execution_time DESC;
[test execution time] 3. Count Total Tests and Filter by Type -- Total tests
SELECT COUNT(*) FROM elementary.dbt_tests;
-- Singular tests only
SELECT COUNT(*) FROM elementary.dbt_tests WHERE type = 'singular';
[dbt_tests table] 4. Average / Median Model Execution Time SELECT
name,
AVG(execution_time) AS avg_execution_time
FROM elementary.dbt_run_results
WHERE resource_type = 'model'
GROUP BY name
ORDER BY avg_execution_time DESC;
[execution time] 5. Recent Test Failures SELECT
id,
test_unique_id,
status,
detected_at,
failures
FROM elementary.elementary_test_results
WHERE status IN ('fail', 'error')
ORDER BY detected_at DESC
LIMIT 20;
[elementary_test_results] 6. Tests That Frequently Warn (Over a Time Window) WITH per_test_summary AS (
SELECT
etr.table_name,
etr.column_name,
etr.test_name,
SUM(CASE WHEN etr.status = 'warn' THEN 1 ELSE 0 END) AS num_warnings,
COUNT(1) AS num_runs
FROM elementary.elementary_test_results etr
INNER JOIN (
SELECT DISTINCT invocation_id
FROM elementary.dbt_invocations
WHERE run_started_at >= CURRENT_DATE - 7 -- last 7 days
) i ON etr.invocation_id = i.invocation_id
GROUP BY 1, 2, 3
)
SELECT
*,
num_warnings / num_runs AS pct_of_time_warns
FROM per_test_summary
WHERE num_warnings > 0
ORDER BY pct_of_time_warns DESC;
[warning frequency] 7. Look Up Invocations (e.g., from Airflow runs) SELECT
invocation_id,
run_started_at,
run_completed_at,
command,
job_name,
cause,
orchestrator,
target_name
FROM elementary.dbt_invocations
ORDER BY run_started_at DESC
LIMIT 10;
[dbt_invocations]
> Tip for your Airflow setup: You can populate job_name in dbt_invocations by setting the DBT_JOB_NAME environment variable in your Cloud Run container, making it easy to distinguish Airflow runs from manual runs. [dbt_invocations] š 0 button š 0 button ā¹ļø Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.