https://linen.dev logo
Join Slack
Powered by
<@U088WCP3B4P> edr monitor --filters "statuses:war...
# ask-elementary-ai
y
@kapa.ai edr monitor --filters "statuses:warn" --owner "@xxxx” --slack-token=XXXXXX --slack-channel-name "test-airflow-alert-notification-1" I'm creating this DAG in airflow to automatically send warnings to a slack channel with elementary. Since the dbt runs every day, it detects warnings everyday, and the warnings detected of today may be exactly the same as those of yesterday. but now I want that the same warnings shouldn’t be sent more than once in a same week, how to configure that with elementary? is there a parameter to configure?
k
A message from kapa.ai
You can “snooze” repeat alerts for the same issue using Elementary’s suppression interval. There are two places you can configure it: 1. Globally on the CLI (what you want here) Add 
--suppression-interval
(in hours) to your 
edr monitor
command. For “no more than once per week” use 7×24 = 168 hours:
Copy code
bash    edr monitor \      --filters "statuses:warn" \      --owner "@xxxx" \      --slack-token XXXXXX \      --slack-channel-name "test-airflow-alert-notification-1" \      --suppression-interval 168
This tells Elementary not to send another alert for the same issue within 168 hours. [[CLI options](https://docs.elementary-data.com/oss/cli-commands#cli-options); [Alerts CLI flags](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-cli-flags)] 2. Per-model/test in dbt 
meta
 You can also set 
alert_suppression_interval
(in hours) on specific models/tests if you want different snooze periods per object, e.g.:
Copy code
yml    models:      - name: my_model_name        meta:          alert_suppression_interval: 168
[[OSS alerts distribution](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-distribution)] If both are set, the dbt project/meta value wins unless you run 
edr monitor
with 
--override-dbt-project-config
. [[Alerts CLI flags](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-cli-flags)] There is **no built‑in “once per calendar week” switch**; the suppression interval is purely “N hours since the last alert for the same issue.”
y
how to test this command in vscode locally
@kapa.ai how to test this command in vscode locally
k
A message from kapa.ai
To test 
edr monitor
locally from VS Code, the docs and threads only cover the same way you’d run it in any shell (VS Code terminal, not something special in the editor): 1. Open the integrated terminal in VS Code Use 
View → Terminal
and make sure it’s running in your dbt project directory. 2. Ensure prerequisites are in place - Elementary dbt package is installed and run (
dbt run --select elementary
) so the Elementary tables exist. [[Monitor error fix](https://elementary-community.slack.com/archives/C02CTC89LAX/p1701958505009259)] - You’ve run 
dbt test
(or your normal dbt job) so there are fresh test results for 
edr monitor
to alert on. [[Alerts skipped reasons](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199)] 3. Set your Slack token env var (optional but typical) In the VS Code terminal:
Copy code
bash    export EDR_SEND_REPORT_SLACK_TOKEN='xoxb-...'
Or pass the token inline, as shown in examples: [[Slack token usage](https://elementary-community.slack.com/archives/C02CTC89LAX/p1700820771698069)] 4. Run your command with suppression interval from the VS Code terminal
Copy code
bash    edr monitor \      --filters "statuses:warn" \      --owner "@xxxx" \      --slack-token "$EDR_SEND_REPORT_SLACK_TOKEN" \      --slack-channel-name "test-airflow-alert-notification-1" \      --suppression-interval 168
The 
--suppression-interval
flag behavior is documented here. [[Alerts CLI flags](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-cli-flags); [CLI options](https://docs.elementary-data.com/oss/cli-commands#cli-options)] 5. Verify suppression is applied - Run 
edr monitor
once and confirm a warning alert is sent. - Run it again shortly after with no new failures; with suppression configured, the same issue should not alert again. [[Alerts CLI flags](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-cli-flags)] The knowledge sources don’t describe any VS‑Code‑specific integration or debugging helpers beyond running 
edr
and dbt commands in a shell, so testing locally is essentially “run the same command you plan to use in Airflow, from the VS Code terminal.”
y
@kapa.ai when i ran this command: edr monitor --filters "statuses:warn" --slack-token "xoxb-3495349835-1278637147202-PtQti15UlM0KazhauyfMSpnQ" --slack-channel-name "test-airflow-alert-notification-1" --suppression-interval 1 it worked, but I got some logs as per below: ________ __ / ____/ /__ __ _ _ __ / /_____ ________ __ / __/ / / _ \/ _ `_ \/ _ \/ __ \/ _/ _ `/ ___/ / / / / /___/ / __/ / / / / / __/ / / / /_/ /_/ / / / /_/ / /_____/_/\___/_/ /_/ /_/\___/_/ /_/\__/\__,_/_/ \__, / /____/ Any feedback and suggestions are welcomed! join our community here - https://bit.ly/slack-elementary 2025-11-26 141352 — INFO — Running with edr=0.20.0 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 3203 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 463 2025-11-26 141359 — WARNING — You are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary WARNINGelementary.monitor.data monitoring.data monitoringYou are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 447 2025-11-26 141400 — INFO — Elementary's database and schema: '"z_yang_xu.elementary"' INFOelementary.monitor.data monitoring.data monitoringElementary's database and schema: '"z_yang_xu.elementary"' 2025-11-26 141400 — INFO — Running internal dbt run to populate alerts INFOelementary.monitor.data monitoring.alerts.data monitoring alertsRunning internal dbt run to populate alerts 2025-11-26 141400 — INFO — Running dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} INFOelementary.clients.dbt.command line dbt runnerRunning dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} 2025-11-26 141410 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 525399 2025-11-26 141413 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 403 2025-11-26 141414 — INFO — Update skipped alerts INFOelementary.monitor.fetchers.alerts.alertsUpdate skipped alerts on 0: /usr/local/lib/python3.12/site-packages/slack_sdk/web/internal_utils.py298 UserWarning: The top-level 
text
argument is missing in the request payload for a chat.postMessage call - It's a best practice to always provide a 
text
argument when posting a message. The 
text
argument is used in places where content cannot be rendered such as: system push notifications, assistive technology such as screen readers, etc. warnings.warn(missing_text_message, UserWarning) Sending alerts |████████████████████████████████████████| 3/3 [100%] in 2.6s (1.14/s) 2025-11-26 141417 — INFO — Update sent alerts INFOelementary.monitor.fetchers.alerts.alertsUpdate sent alerts DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command run -s elementary_cli.update_alerts.update_sent_alerts --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"alert_ids": ["fbddcfcb-6326-4ebe-9402-6a3a41d0913d.test.payfit.dbt_constraints_primary_key_stg_company_lifecycle__company_lifecycle_global_company_id.3d29d488b1", "fbddcfcb-6326-4ebe-9402-6a3a41d0913d.test.payfit.dbt_constraints_primary_key_stg_gspread__fact_payfiters_cs_day_snapshot_date__payfiter_email.2da250ee97", "fbddcfcb-6326-4ebe-9402-6a3a41d0913d.test.payfit.unique_stg_zuora__account_company_id.a3422d5ad1"], "sent_at": "2025-11-26 141417"} my question is where does the days_back = 1 come from? I didn't set it up
k
A message from kapa.ai
days_back
is being set internally by 
edr monitor
, not by your command-line arguments. From the logs you shared (and similar ones in the knowledge sources), 
edr monitor
always runs an internal dbt job to build the alerts model and then calls two macros with `days_back`: - 
dbt run -s elementary_cli.alerts.alerts_v2 --vars {"days_back": 1}
- 
run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}}
- 
run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}}
This pattern appears in multiple examples, and in all of them the user did not pass 
--days-back
to `edr monitor`; 
1
is simply the default lookback window Elementary uses to collect alerts for the monitor run. [[Monitor logs days_back](https://elementary-community.slack.com/archives/C02CTC89LAX/p1714693674739499); [Monitor internal run with days_back](https://github.com/elementary-data/elementary/issues/2042)] A support reply also clarifies that for alerts “the default 
--days-back
for the alerts is 1” unless you override it. [[Default alerts days_back](https://elementary-community.slack.com/archives/C02CTC89LAX/p1683130424362839)] So in your case: - You didn’t specify 
--days-back
on the CLI. - 
edr monitor
fell back to its default of 
days_back = 1
when running the internal dbt model and macros. - That’s why you see 
{"days_back": 1}
in the logged dbt commands. If you want a different window, you’d need to configure 
days_back
(for example via dbt vars/meta); however, the provided knowledge sources don’t show a way to change that default specifically for 
edr monitor
beyond the general 
days_back
configuration used by Elementary tests and alerts. [[days_back var explanation](https://elementary-community.slack.com/archives/C02CTC89LAX/p1685471780142259); [Monitor passing days_back var](https://github.com/elementary-data/elementary/issues/1644)]
y
@kapa.ai can i set the suppression-interval as 0.5?
k
A message from kapa.ai
No — 
suppression-interval
/ 
alert_suppression_interval
is documented and used as an integer number of hours, not a float. - In dbt 
meta
/ config: “The accepted value is in hours, so 1 day snooze is 
alert_suppression_interval: 24
.” [[OSS alerts distribution](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-distribution)] - In the CLI: 
edr monitor --suppression-interval [int]
with “duration in hours.” [[Alerts CLI flags](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#suppression-interval-flag); [CLI options](https://docs.elementary-data.com/oss/cli-commands#cli-options)] There’s no mention in the sources that fractional hours (like 
0.5
) are supported, and one Slack thread even shows type issues when the value isn’t a proper numeric type. [[Monitor type error](https://elementary-community.slack.com/archives/C02CTC89LAX/p1706346335287079)] So you should use whole hours only (e.g., 
0
or 
1
), not 
0.5
.
y
@kapa.ai i run it again and now i got no notifications anymore, here's the log, tell me why: 2025-11-26 142851 — INFO — Running with edr=0.20.0 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 3203 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 463 2025-11-26 142854 — WARNING — You are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary WARNINGelementary.monitor.data monitoring.data monitoringYou are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 447 2025-11-26 142854 — INFO — Elementary's database and schema: '"z_yang_xu.elementary"' INFOelementary.monitor.data monitoring.data monitoringElementary's database and schema: '"z_yang_xu.elementary"' 2025-11-26 142854 — INFO — Running internal dbt run to populate alerts INFOelementary.monitor.data monitoring.alerts.data monitoring alertsRunning internal dbt run to populate alerts 2025-11-26 142854 — INFO — Running dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} INFOelementary.clients.dbt.command line dbt runnerRunning dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} 2025-11-26 142903 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 508173 2025-11-26 142906 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 1267 2025-11-26 142908 — INFO — Update skipped alerts INFOelementary.monitor.fetchers.alerts.alertsUpdate skipped alerts
k
A message from kapa.ai
Two separate Elementary behaviors from the docs explain this: 1. Each alert is only sent once per issue (and per dbt run) After the first 
edr monitor
run, those alerts were marked as 
sent
in the Elementary alerts table. When you immediately run 
edr monitor
again on the same dbt results, there are no “pending” alerts left, so nothing is sent and you see only: > 
INFO — Update skipped alerts
This is by design to avoid spamming: > “Each alert is only sent once, to avoid spaming. The command sends the alert + updates the alert status to 
sent
.” [[Slack alerts once](https://elementary-community.slack.com/archives/C02CTC89LAX/p1691482831550239)] A similar explanation is given for “why is 
edr monitor
not sending alerts anymore”: > “After each time elementary monitor command is executed and elementary sends the alerts, it marks the alerts that were sent as ‘sent’. So if there were no dbt run / dbt test runs … before the next run … there are no new alerts to send so elementary sends nothing.” [[Why monitor not sending](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829)] 2. You set 
--suppression-interval 1
 That adds an extra “snooze” layer: Elementary won’t send a new alert for the same issue within 1 hour of the last time it sent it. [[Suppression flag](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#suppression-interval-flag)] So even if a test fails again with the same issue shortly after, it will still be skipped during that 1‑hour interval. Putting it together for your second run: - The same issues had already been alerted and marked as 
sent
in the first run. - You did not run a new 
dbt test
invocation with new failures in between. - 
edr monitor
therefore finds no new, unsent alerts matching your filters, and—combined with your 1‑hour suppression—**skips** them instead of sending again. To see alerts again, you need: 1. A new `dbt test`/`dbt run` invocation that produces fresh failures/warnings, and then 2. Run 
edr monitor
after that; or 3. Wait until the suppression interval has elapsed and there is a new detection of the same issue.
y
@kapa.ai if i run this at first: edr monitor --filters "statuses:warn" --owner "@xxxx” --slack-token=XXXXXX --slack-channel-name "test-airflow-alert-notification-1" then 5 minutes later i run this: edr monitor --filters "statuses:warn" --owner "@xxxx” --slack-token=XXXXXX --slack-channel-name "test-airflow-alert-notification-1" --suppression_interval 1 will the --suppression_interval 1 take effect already this time or it will take effect in the next run? Will i receive any notification this time or not?
k
A message from kapa.ai
It will already take effect on that second run, and you should not receive notifications again for the same issues. From the docs and Slack answers: - The suppression window is defined as: > “a ‘snooze’ period for alerts on the same issue… Elementary won’t send new alerts on the same issue that are generated within suppression interval.” [[OSS alerts distribution](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#alerts-distribution); [Suppression flag](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#suppression-interval-flag)] - The suppression is evaluated per 
edr monitor
run, using the last sent time stored in the alerts table. That means as soon as you run 
edr monitor
with 
--suppression-interval 1
, it will compare “now” to “last sent time” and skip anything within 1 hour. [[Alerts tables & statuses](https://elementary-community.slack.com/archives/C02CTC89LAX/p1685477527642749); [Why alerts skipped](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199)] In your scenario: 1. First run (no suppression flag): - All matching 
warn
alerts are sent. - Their status is marked as 
sent
with a timestamp. 2. Second run 5 minutes later (with 
--suppression-interval 1
): - Elementary sees the same issues with 
last_sent_at
≈ 5 minutes ago. - Since 5 minutes < 1 hour, they fall inside the suppression interval. - Result: those alerts are skipped and you do not get them again on this second run. So: the suppression interval applies immediately on the run where you add `--suppression-interval 1`; it does not require “one run to warm up.”
y
@kapa.ai ok, now if i run a third run: edr monitor --filters "statuses:warn" --owner "@xxxx” --slack-token=XXXXXX --slack-channel-name "test-airflow-alert-notification-1" i didn't specify any suppression interval in the third run, will it still send notifications or not
k
A message from kapa.ai
In the third run (without 
--suppression-interval
), Elementary will send the alerts again, assuming there are still 
warn
-status issues matching your filters. Key points from the docs: - The CLI flag is **per run only**; each 
edr monitor
invocation uses whatever 
--suppression-interval
is passed on that run, or falls back to the default of 
0
hours if none is given. [[CLI options](https://docs.elementary-data.com/oss/cli-commands#cli-options); [Suppression flag](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#suppression-interval-flag)] - Default: > “The flag configuration is the suppression interval duration in hours, and the default is 0 hours (no alert suppression).” [[Suppression flag](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#suppression-interval-flag)] You haven’t shown any 
alert_suppression_interval
configured in dbt meta/project, so the only suppression applied was on the second run, from the CLI. On the third run, since: - You omit 
--suppression-interval
, and - There is no stated dbt config overriding it, the effective suppression interval goes back to 
0
hours. With 
0
, Elementary does not snooze those issues, so the same 
warn
alerts are eligible to be sent again on that third run (provided they are still present and match the filters).
y
@kapa.ai so why it's not sending notifications this time according to the log: ________ __ / ____/ /__ __ _ _ __ / /_____ ________ __ / __/ / / _ \/ _ `_ \/ _ \/ __ \/ _/ _ `/ ___/ / / / / /___/ / __/ / / / / / __/ / / / /_/ /_/ / / / /_/ / /_____/_/\___/_/ /_/ /_/\___/_/ /_/\__/\__,_/_/ \__, / /____/ Any feedback and suggestions are welcomed! join our community here - https://bit.ly/slack-elementary 2025-11-26 150345 — INFO — Running with edr=0.20.0 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 4135 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 463 2025-11-26 150351 — WARNING — You are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary WARNINGelementary.monitor.data monitoring.data monitoringYou are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 447 2025-11-26 150352 — INFO — Elementary's database and schema: '"z_yang_xu.elementary"' INFOelementary.monitor.data monitoring.data monitoringElementary's database and schema: '"z_yang_xu.elementary"' 2025-11-26 150352 — INFO — Running internal dbt run to populate alerts INFOelementary.monitor.data monitoring.alerts.data monitoring alertsRunning internal dbt run to populate alerts 2025-11-26 150352 — INFO — Running dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} INFOelementary.clients.dbt.command line dbt runnerRunning dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} 2025-11-26 150402 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 1637777 2025-11-26 150406 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 4965 2025-11-26 150407 — INFO — Update skipped alerts INFOelementary.monitor.fetchers.alerts.alertsUpdate skipped alerts DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command run -s elementary_cli.update_alerts.update_skipped_alerts --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"alert_ids": ["9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dim_charge_subscriptions_overlapping_products", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_constraints_primary_key_stg_company_lifecycle__company_lifecycle_global_company_id.3d29d488b1", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.not_null_dim_charge_subscriptions_add_on_name.aa358e39bf", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_utils_mutually_exclusive_ranges_wrk__dim_subscriptions_allowed__service_activation_date__zuora_company_id_subscription_type__coalesce_cancelled_date_9999_12_31_.15836b9a9f", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dim_accounts_companies_country_code_compare", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.unique_stg_zuora__account_company_id.a3422d5ad1", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.compare_company_country_code_between_sources.8ac8c870d0", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dim_companies_montly_plan_group_all_mapped", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_constraints_foreign_key_fact_nps_account_id__account_id__ref_dim_accounts_.5ffe45d3df", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.not_null_dim_companies_account_id.c14e6766c7", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_constraints_foreign_key_dim_companies_account_id__account_id__ref_dim_accounts_.a7cc08be67", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_constraints_foreign_key_wrk__mart_performance_sales_payfiter_email__payfiter_email__ref_dim_payfiters_legacy_.97bfc18d73", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_constraints_foreign_key_mart_tnps_account_id__account_id__ref_dim_accounts_.339cac2d4c", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.onboarding_status_check.11d76dbb4d", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.product_activation_test.9486504732", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_utils_expression_is_true_wrk__dim_companies_is_account_deleted___false.8a394d7fc4", "9c94d846-2355-4eb1-ad7c-4c3efcaf0618.test.payfit.dbt_constraints_primary_key_stg_gspread__fact_payfiters_cs_day_snapshot_date__payfiter_email.2da250ee97"]}
k
A message from kapa.ai
Elementary is skipping those alerts on the third run because it treats them as duplicates from previous monitor runs, not because of the suppression interval flag on this run. From the logs: - 
get_pending_alerts
returns alerts (big result size). - Then 
get_last_alert_sent_times
runs and returns data. - Then you see 
INFO — Update skipped alerts
and a 
run -s elementary_cli.update_alerts.update_skipped_alerts
with a long list of 
alert_ids
. This “pending + last_sent_times + update_skipped_alerts” pattern means: 1. Elementary found alerts for those tests in 
alerts_v2
. 2. It also found that for the same issues there are already alerts recorded in the alerts table for the same latest dbt invocation. 3. Since you already ran 
edr monitor
earlier on the same failures, those older alerts are treated as duplicates and marked as 
skipped
, not resent. [[Why alerts skipped](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199); [Skip duplicate alerts](https://elementary-community.slack.com/archives/C02CTC89LAX/p1703151833058309)] Key points from the docs / threads that apply here: - Elementary sends only the latest alert per issue, and doesn’t resend the same alert again if it already sent it for that dbt invocation. [[Skip duplicate alerts](https://elementary-community.slack.com/archives/C02CTC89LAX/p1703151833058309)] - If you run 
edr monitor
again on the same dbt results (no new 
dbt test
run with new failures), there are “no new alerts to send,” so nothing is sent; existing ones are updated to 
sent
or 
skipped
. [[Why monitor not sending](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829)] - Suppression interval is an additional “snooze” layer, but even with 
0
hours suppression, Elementary still won’t resend the same alerts for the same invocation; you need new test results. [[Suppression flag](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#suppression-interval-flag); [Reasons alerts skipped](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199)] So in your timeline: 1. First `edr monitor`: sends the warn alerts, marks them 
sent
. 2. Second 
edr monitor
with `--suppression-interval 1`: new alerts from the same failures are already within the 1‑hour window and/or considered duplicates, so they’re skipped. 3. Third 
edr monitor
without suppression flag, but still no new 
dbt test
run: alerts from the same failures are seen as duplicates from prior monitor runs → 
update_skipped_alerts
, no Slack messages. To get notifications again for those tests, you need: - A new 
dbt test
(or 
dbt build
) invocation that re-detects the failures, and then - Run 
edr monitor
after that.
y
@kapa.ai now what's the reason why the notification is not sent with the below log: ________ __ / ____/ /__ __ _ _ __ / /_____ ________ __ / __/ / / _ \/ _ `_ \/ _ \/ __ \/ _/ _ `/ ___/ / / / / /___/ / __/ / / / / / __/ / / / /_/ /_/ / / / /_/ / /_____/_/\___/_/ /_/ /_/\___/_/ /_/\__/\__,_/_/ \__, / /____/ Any feedback and suggestions are welcomed! join our community here - https://bit.ly/slack-elementary 2025-11-26 151809 — INFO — Running with edr=0.20.0 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_latest_invocation", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 3185 DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_adapter_type_and_unique_id", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 463 2025-11-26 151816 — WARNING — You are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary WARNINGelementary.monitor.data monitoring.data monitoringYou are using incompatible versions between edr (0.20.0) and Elementary's dbt package (0.19.2). To fix please update your packages.yml, and run: dbt deps && dbt run --select elementary DEBUGelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_elementary_database_and_schema", "macro_args": {}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 447 2025-11-26 151816 — INFO — Elementary's database and schema: '"z_yang_xu.elementary"' INFOelementary.monitor.data monitoring.data monitoringElementary's database and schema: '"z_yang_xu.elementary"' 2025-11-26 151816 — INFO — Running internal dbt run to populate alerts INFOelementary.monitor.data monitoring.alerts.data monitoring alertsRunning internal dbt run to populate alerts 2025-11-26 151816 — INFO — Running dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} INFOelementary.clients.dbt.command line dbt runnerRunning dbt command run -s elementary_cli.alerts.alerts_v2 --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project --vars {"days_back": 1} 2025-11-26 151824 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_pending_alerts", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 1523765 2025-11-26 151828 — INFO — Running dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project INFOelementary.clients.dbt.command line dbt runnerRunning dbt command --log-format json run-operation elementary.log_macro_results --args {"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}} --project-dir /usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project DEBUGelementary.clients.dbt.command line dbt runnerResult bytes size for command '['--log-format', 'json', 'run-operation', 'elementary.log_macro_results', '--args', '{"macro_name": "elementary_cli.get_last_alert_sent_times", "macro_args": {"days_back": 1, "type": null}}', '--project-dir', '/usr/local/lib/python3.12/site-packages/elementary/monitor/dbt_project']' is 4965 2025-11-26 151829 — INFO — Update skipped alerts INFOelementary.monitor.fetchers.alerts.alertsUpdate skipped alerts
k
A message from kapa.ai
Elementary is skipping alerts in this run because it considers all of them already alerted-on for the latest dbt invocation, so there are no “new” alerts to send. From the log: - 
get_pending_alerts
returns data (large result size) → there are alerts in 
alerts_v2
. - 
get_last_alert_sent_times
also returns data. - Immediately after, you see 
INFO — Update skipped alerts
, with no “Sending alerts …” line and no Slack errors. This pattern matches how Elementary behaves when it treats alerts as duplicates of issues it has already alerted on for the same dbt run: - Support explains that Elementary may “skip alerts if the tests are failed” when they’re duplicates, for example if 
dbt test
ran multiple times with the same failure but 
edr monitor
should only send the latest alert once. [[Skip duplicate alerts](https://elementary-community.slack.com/archives/C02CTC89LAX/p1703151833058309)] - They also clarify that after 
edr monitor
sends alerts once, if you run it again without a new 
dbt test
/ 
dbt run
with new failures, “there are no new alerts to send so elementary sends nothing.” [[Why monitor not sending](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829)] - Another thread describes exactly your symptom: repeated 
edr monitor
runs only show “Update skipped alerts” because the alerts are already recorded, not new. [[Skipping alerts reasons](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199)] So for this specific run: 1. The failures/warnings you care about have already produced alerts in a previous 
edr monitor
run (and corresponding “sent”/“skipped” records exist). 2. You haven’t run a new `dbt test`/`dbt build` that generates a new invocation with fresh failures. 3. When this 
edr monitor
run compares 
pending_alerts
with 
last_alert_sent_times
, everything it finds is treated as already handled, so it calls 
update_skipped_alerts
and sends nothing. To get notifications again, the docs and threads consistently say you need: - A new dbt invocation (e.g. re-run 
dbt test
so new results land in 
elementary_test_results
/ 
alerts_v2
), then - Run 
edr monitor
after that; only then will Elementary consider those alerts “new” and send them. [[Data flow to alerts](https://elementary-community.slack.com/archives/C02CTC89LAX/p1688649713861769); [Monitor after dbt run](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829)]
y
@kapa.ai i thought it's because of the --suppression-interval 1 I set
k
A message from kapa.ai
The behavior you’re seeing is not caused by the 
--suppression-interval 1
you used earlier; it’s from Elementary’s core “don’t resend the same alert for the same dbt run” logic. From the docs and Slack threads: 1. Alerts are only sent once per issue per dbt invocation After 
edr monitor
sends an alert, it marks it as 
sent
. If you re‑run 
edr monitor
on the same dbt results (no new 
dbt test
/ 
dbt run
), Elementary finds no new alerts to send and just updates them as skipped/handled. [[Why monitor not sending](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829); [Duplicate alerts skipped](https://elementary-community.slack.com/archives/C02CTC89LAX/p1703151833058309)] 2. **Suppression interval is an extra snooze layer, not the primary reason here** - The suppression flag means: > “Elementary won’t send new alerts on the same issue that are generated within suppression interval.” [[Suppression flag](https://docs.elementary-data.com/oss/guides/alerts/alerts-configuration#suppression-interval-flag)] - But even with suppression = 0, Elementary still won’t re‑alert on the same issue for the same invocation – that’s already handled by the “don’t resend duplicates” logic. [[Duplicate alerts skipped](https://elementary-community.slack.com/archives/C02CTC89LAX/p1703151833058309)] In your later runs where you see only:
Copy code
text INFO — Update skipped alerts
the key reasons are: - You didn’t run a new 
dbt test
between monitor runs, so there’s no new invocation / new failures. [[Why monitor not sending](https://elementary-community.slack.com/archives/C02CTC89LAX/p1684524581057829)] - The alerts Elementary finds are all tied to the same latest invocation and already have 
sent
records, so they are treated as duplicates and skipped, regardless of whether 
--suppression-interval
is present on that specific run. [[Reasons alerts skipped](https://elementary-community.slack.com/archives/C02CTC89LAX/p1696945250119199)] So: - The first monitor run sends the alerts. - Subsequent runs on the same dbt results will not send them again, even if suppression is 0. - The 
--suppression-interval 1
can prevent alerts on new failures within 1 hour, but it’s not what’s blocking these re‑runs; the duplicate‑alert logic is.
38 Views
Open in Slack
PreviousNext
Powered by