Two separate things are likely happening here: 1. The “No test results” message (empty report) Common root causes from similar cases: ◦ dbt vs edr using different targets/profiles –

dbt test

may be writing to one schema, while

edr report

is reading from another. Check that the

elementary

profile used by

edr

points to the same database/schema where

elementary_test_results

lives, and that this table actually has recent rows. [Target mismatch; Profile config] ◦ Results not being written to

elementary_test_results

– if you only see transient tables like

test_...elementary_schema_changes__...

or

test_...elementary_freshness_anomalies_...

and

elementary_test_results

is empty, then Elementary’s models/hooks aren’t loading results. You must: i. Run

dbt run --select elementary

ii. Then run

dbt test

iii. Then run

edr report

Also ensure the

on-run-end

hook (

{{ elementary.on_run_end() }}

) isn’t disabled and that flags like

disable_tests_results

/

disable_run_results

are not set. [Blank report & empty results; Hooks/flags] ◦ CLI/dbt package version mismatch – incompatible

edr

vs Elementary dbt package versions can lead to “No test results” even when tables are populated. [Version warning example] ◦ dbt 1.8+ materialization behavior – if you’re on dbt 1.8, you may need

flags: require_explicit_package_overrides_for_builtin_materializations: false

in

dbt_project.yml

so Elementary can capture result rows. [Materialization issue; Result-rows troubleshooting] 2. The report file being > 1 GB There is a known pattern where reports become extremely large (hundreds of MB or more), especially when: ◦ There is a very high volume of tests / anomaly points (e.g., hourly anomaly tests with long training periods and “hour of day” seasonality), which makes the JSON payload huge. [Large report with hourly tests; Growing report size] ◦ Adding many custom dbt tests significantly increased report size for another user. [Custom tests & huge report] Things you can try: ◦ Run

edr report -d

smaller_number (e.g.

-d 3

) to limit how far back Elementary collects results for the report. [Days-back flag] ◦ If the Elementary tables themselves have grown very large, a full-refresh of Elementary models can reduce history (at the cost of losing old history):

dbt run --select elementary --full-refresh

. [Full-refresh workaround] Because your file is >1 GB and opens as “No test results”, it’s likely a combination of: • The browser struggling with such a large HTML/JSON payload (leading to the UI falling back to the “No test results” screen), and • One of the configuration issues above (profile/target mismatch, results not loaded into

elementary_test_results

, or version/materialization issues). Concrete next checks: 1. In your warehouse, confirm: ◦

elementary_test_results

has recent rows (check

generated_at

). ◦

dbt_models

,

dbt_tests

, and

dbt_run_results

also have recent data. [Troubleshooting empty report] 2. Confirm your

profiles.yml

has an

elementary

profile pointing to that same schema, and that

edr report

is using it. 3. Re-run in order:

dbt run --select elementary
   dbt test
   edr report -d 3

4. If the HTML is still ~1 GB, try opening it in a different browser (there’s at least one case where Safari worked but Chrome showed “No test results” for the same file). [Browser difference] If you can share (privately) the size of

elementary_output.json

, your dbt/edr versions, and whether

elementary_test_results

has recent data, that would help narrow down which of these is the main culprit. 👍 0 button 👎 0 button ℹ️ Tip: Mention @elementary.ai in the thread for follow-ups or DM the app for 1-to-1 help.