The edr report command takes everything Elementary has collected in your warehouse and renders it into a self-contained HTML file. One command, one file, everything you need to assess data quality at a glance.
edr reportBy default, this creates elementary_report.html in the ./edr_target directory. Open it in a browser and you have a working data quality dashboard, with no server, no login, and no hosting required for personal use.
The flags that matter
Most of the time you’ll use edr report with a handful of flags:
| Flag | What it does |
|---|---|
--file-path report.html | Custom output location |
--target-path ./reports | Change the output directory |
--days-back 7 | Limit to last 7 days of data |
--select last_invocation | Show only the most recent run |
--project-name "Analytics" | Custom name in the report header |
--disable-samples | Hide data samples (useful for PII) |
The --days-back and --select flags are the ones you’ll reach for most often. Elementary’s incremental models accumulate history indefinitely, and a report trying to render months of test results gets unwieldy fast. Neither flag deletes historical data — they only control what the report shows. The full history stays in your warehouse tables, available for BI dashboards and ad hoc queries.
--disable-samples is worth mentioning separately. By default, when a test fails, the report includes sample rows from the failing records. That’s useful for debugging but inappropriate for columns with PII. Turn it off globally if your warehouse has sensitive data mixed in with test outputs.
Two common invocations
For a quick look at your latest run:
edr report --select last_invocation --file-path ./reports/latest.htmlFor a weekly summary:
edr report --days-back 7 --file-path ./reports/weekly.htmlThe last_invocation selector is particularly useful in CI or during debugging sessions where you want to understand what just happened without wading through weeks of history.
Tag-based filtering
If you’ve tagged your tests, you can generate focused reports:
edr report --select tag:criticalThis only works if you’ve applied tags in your model and test definitions. The discipline of consistent tagging pays off here — a report filtered to tag:critical that actually contains your most important models is more useful than an unfiltered report where critical and exploratory tests compete for attention. See Elementary dashboard organization for how to think about tagging strategy.
What the command actually reads
edr report reads from Elementary’s warehouse tables (elementary_test_results, dbt_run_results, dbt_models), not from live dbt runs. This means the report reflects data as of the last time dbt run or dbt test executed with the Elementary hooks active. Running edr report twice in a row produces the same report unless dbt has run in between.
The separation also means report generation is cheap. It does not trigger any dbt runs, re-execute tests, or write to your warehouse. It’s a read-only operation against tables that already exist.
Report freshness
Because the command is a read against historical data, you have to think about when to generate reports. Generating before a dbt run gives you yesterday’s picture. Generating immediately after gives you the current state.
For teams using orchestration tools, the right pattern is to run edr report (or edr send-report for hosted versions) as a downstream task after each dbt build. That way the report always reflects the most recent run. See Elementary report hosting for how to automate this in GitHub Actions or Airflow.