@kapa.ai Is there a supported way to run

edr monitor

without sending the alerts directly, but instead get the generated alerts in a structured format (e.g. JSON) so that our wrapper could pick them up and send them through our gateway?

Thinking completed No, there is currently no supported way to run

edr monitor

to output structured alert data (such as JSON or text/markdown to stdout or a file) instead of dispatching alerts directly [Slack discussion]. Running

edr monitor

strictly requires an active destination integration (either a Slack token and channel, a Slack webhook, or a Microsoft Teams webhook), and it will throw an

InvalidArgumentsError

if none are provided [InvalidArgumentsError discussion]. Common Workaround If you want your wrapper or custom gateway to handle the alerts in a structured format, the typical approach is to bypass `edr monitor`'s dispatching and query Elementary's underlying warehouse tables directly [Slack discussion]: 1. Query `alerts_v2`: Elementary stores alerts in an incremental tracking table called

alerts_v2

in your configured Elementary schema [alerts_v2 discussion]. 2. Access the JSON payload: Each row contains a

data

column stored in JSON format containing full alert context (e.g.,

model_unique_id

,

test_unique_id

,

status

,

severity

,

test_rows_sample

,

owners

,

tags

, etc.) [alerts_v2 discussion]. 3. Filter pending alerts: You can filter by

status = 'pending'

(or

sent_at IS NULL

) to read new alerts, route them through your custom gateway, and manage their status within your own pipeline [alerts_v2 discussion]. 👍 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 is this alerts_v2 table in which version? Do i need to run some commands to generate this table? Because I can see only 5 alert views (not tables): •

ALERTS_ANOMALY_DETECTION

•

ALERTS_DBT_MODELS

•

ALERTS_DBT_SOURCE_FRESHNESS

•

ALERTS_DBT_TESTS

•

ALERTS_SCHEMA_CHANGES

Thinking completed Which version introduced alerts_v2? The

alerts_v2

table was introduced in version

0.14.0

of Elementary [Slack discussion; alerts_v2 overview]. Starting in

0.14.0

, older views like

alerts_dbt_models

and related separate alert views were deprecated in favor of this single central table [Slack discussion; alerts_v2 overview]. If you only see the individual views (such as

ALERTS_DBT_MODELS

,

ALERTS_DBT_TESTS

, etc.), your Elementary dbt package is likely running version

0.13.x

or older [Slack discussion]. Do you need to run commands to generate it? Yes, if you want

alerts_v2

created and populated: 1. Upgrade your Elementary versions: Make sure both your Elementary dbt package (in

packages.yml

) and your CLI (

edr

) are upgraded to at least version

0.14.0

(or matching latest compatible versions) [Slack discussion; version mismatch fix]. 2. Build the package models: Run the following dbt command to create the updated package models in your warehouse:dbt run -s elementary[version mismatch fix] 3. Populate the alerts: The

alerts_v2

incremental table is populated when

edr monitor

runs [alerts_v2 workflow]. Internally, the CLI executes a dbt run targeting

alerts_v2

(for example,

dbt run -m elementary_cli.alerts.alerts_v2

) using the artifacts collected by the Elementary dbt package [CLI execution logs]. _(Note: Also verify that the

schema

defined in your dedicated

elementary

target within

profiles.yml

points exactly to the schema where your Elementary models reside, as mismatched schemas can cause

alerts_v2

to be created in a different schema or appear empty [schema configuration; version mismatch fix].)_ 👍 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 but what if I cannot run edr monitor because I don't have internet access? I could only run this edr monitor (and it will probably fail) but even failed, it would generate this table for me?

Thinking completed If you run

edr monitor

without internet access before preparing your environment, it will fail early during its package dependency step before it ever runs the internal model to create or populate

alerts_v2

[stand-alone edr report]. Here is why that happens and how you can work around it in an offline environment: Why it fails before creating alerts_v2 When

edr monitor

runs, it relies on an internal dbt project located inside the Elementary Python package (e.g.,

.../site-packages/elementary/monitor/dbt_project

) [internal dbt explanation]. Its execution sequence is: 1. It checks if the internal dbt dependencies (

elementary

and

dbt_utils

) exist inside

site-packages/elementary/monitor/dbt_project/dbt_packages

[internal dbt explanation]. 2. If those dependencies are missing, it attempts to run

dbt deps

and connect to

hub.getdbt.com

[internal dbt explanation]. Without internet access or proxy authorization, this fails immediately with network or authentication errors [stand-alone edr report]. 3. Only after

dbt deps

succeeds does it execute

dbt run -m elementary_cli.alerts.alerts_v2

to populate the

alerts_v2

table in your warehouse [execution log]. Because the package check fails first,

alerts_v2

will never be created or updated if you simply run it without preparation [stand-alone edr report]. How to make it populate offline To get

alerts_v2

populated in an air-gapped or restricted environment, you must pre-install the dependencies into the internal project beforehand [internal dbt explanation; stand-alone edr report]: 1. Pre-populate internal dbt packages on an internet-connected machine (or during Docker build) Locate the Elementary internal project directory inside Python's

site-packages

and run

dbt deps

pointing directly to it [internal dbt explanation; manual package installation]:

dbt deps --project-dir /path/to/site-packages/elementary/monitor/dbt_project

2. Copy the populated folder to your offline environment Ensure the resulting

site-packages/elementary/monitor/dbt_project/dbt_packages

folder is present and that the running user has write permissions to that directory [internal dbt explanation]. Once these packages are pre-populated, the CLI will skip the internet download step and successfully run the internal dbt steps against your warehouse [stand-alone edr report]. Alternative: Run the internal model directly If you only want to populate the

alerts_v2

table in your warehouse so your wrapper can query it, you can bypass the

edr

CLI alert dispatching entirely by running the internal model directly using dbt (once the dependencies above are present) [execution log]:

dbt run -m elementary_cli.alerts.alerts_v2 --project-dir /path/to/site-packages/elementary/monitor/dbt_project --profiles-dir /path/to/profiles

This runs the exact internal model

edr monitor

uses to merge and update the

alerts_v2

table [execution log]. Your custom wrapper can then read the alerts straight from

alerts_v2

without

edr

trying to send notifications to Slack or Teams. 👍 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 I can run edr report but this one will not generate this table alerts_v2 which only edr monitor is doing?

Thinking completed Yes, that is correct. *`edr report` will not generate or populate the

alerts_v2

table*—that step is performed by

edr monitor

[command difference; alerts_v2 flow]. While both commands use Elementary's internal dbt project, their operations differ: •

edr monitor

runs an internal dbt step (

dbt run -m elementary_cli.alerts.alerts_v2

) to populate and update the

alerts_v2

table before evaluating and sending out alerts [alerts_v2 flow; CLI execution logs]. •

edr report

only queries existing tables and artifacts (such as

elementary_test_results

, models, sources, and exposures) via

run-operation

macros to build the standalone HTML report file; it does not build or populate

alerts_v2

[edr report logs]. 👍 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 one last question: when

edr monitor

populates the

alerts_v2

table and sends the alerts, what does it do to make sure the old alerts are not sent again? Does it change any columns? If so, which ones, and what values are they changed to?

Thinking completed When

edr monitor

processes alerts, it prevents older or duplicate alerts from being resent by running internal dbt update operations against

alerts_v2

and modifying two specific columns [alerts_v2 tracking; update alerts dbt command]: 1. Columns Modified •

status

: Tracks the lifecycle state of the alert [alerts_v2 tracking]. •

sent_at

: Records the timestamp when the alert action was dispatched [alerts_v2 tracking; update alerts dbt command]. 2. Values They Are Changed To • Initial state: When alerts are first created/populated in

alerts_v2

, the

status

is set to

'pending'

, and

sent_at

is left unset (

NULL

, or a sentinel date like

'1970-01-01 00:00:00'

depending on the warehouse) [pending status; ClickHouse sentinel]. • After sending successfully: ◦

status

is updated to

'sent'

[alert deduplication]. ◦

sent_at

is populated with the dispatch timestamp (e.g.,

'2025-10-29 11:34:33'

) [update alerts dbt command]. • If treated as a duplicate or suppressed: ◦

status

is updated to

'skipped'

[alert deduplication; alerts_v2 tracking]. 3. How It Checks on Subsequent Runs On subsequent executions,

edr monitor

compares incoming pending test results against the previous alert history (retrieved via internal queries like

elementary_cli.get_last_alert_sent_times

) [CLI macro execution; skip duplicate alerts]. If an alert has already been marked as

sent

or

skipped

for that failure and invocation, Elementary identifies it as already handled, invokes

update_skipped_alerts

, and does not resend it [skip duplicate alerts; alert deduplication]. 👍 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 I'm just wondering this command

dbt run -m elementary_cli.alerts.alerts_v2 --project-dir /path/to/site-packages/elementary/monitor/dbt_project --profiles-dir /path/to/profiles

does

alerts_v2

need the main project's artifacts from

.dbt-target

? does it need the main project's

manifest.json

or

run_results.json

?

Thinking completed No,

alerts_v2

does not need the main project’s local artifacts from your

target

folder, nor does it read directly from

manifest.json

or

run_results.json

[Slack answer]. Elementary does not read from local

.json

artifact files when running these models; instead, it reads from the database tables and views already populated in your data warehouse by the Elementary dbt package during your dbt invocations [Slack answer; alerts_v2 info]. When you run that command: 1. It queries the metadata and results that the dbt package previously loaded into your warehouse schema (such as

elementary_test_results

,

dbt_models

,

dbt_tests

, etc.) via dbt hooks [package models; elementary_test_results]. 2. It processes and transforms those warehouse rows to build and update the

alerts_v2

incremental table [alerts_v2 info]. As long as your

--profiles-dir

points to the profile and target that can connect to the warehouse schema containing those populated Elementary tables, it does not require access to your main project's local target directory or JSON artifacts [CLI install guide]. 👍 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 for edr report can I set up a spesific target path?

Thinking completed Yes, you can specify a target path for

edr report

[CLI options]. If not specified, the default directory is

./edr_target

[CLI options]. You can configure it in a few different ways: 1. Using the --target-path CLI flag Specify the output directory where logs and report files should be saved:

edr report --target-path /path/to/target_directory

[CLI options; target path usage] 2. Using an Environment Variable Set the

EDR_REPORT_TARGET_PATH

environment variable before running the command:

export EDR_REPORT_TARGET_PATH="/path/to/target_directory"
edr report

[target path usage; CLI options] 3. Setting the exact file path If you want to define both the destination folder and the exact HTML file name (rather than having it default to

elementary_report.html

), use the

--file-path

option or `EDR_REPORT_FILE_PATH`:

edr report --file-path "/path/to/target_directory/my_report.html"

[CLI options] 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.