Elementary dashboard organization

Elementary reports and dashboards are most useful when organized by audience rather than by completeness. A single unfiltered report across all domains tends to be too broad to act on.

Organize by how your team thinks, not by how Elementary is structured

Elementary’s default organization is by model — every test result is associated with the model it ran against. That’s the right structure for the underlying data. It’s not necessarily the right structure for the dashboard.

Group by domain if you have distinct teams that own distinct data areas. Marketing analysts don’t need visibility into finance model failures; the finance team doesn’t need to see marketing attribution test results. A finance-specific dashboard — either a filtered Elementary report or a BI dashboard querying elementary_test_results with a domain filter — serves each team better than a unified view where they have to mentally filter noise.

Group by criticality if you have a tiered model. Tier-1 models are revenue-impacting; tier-2 are operational; tier-3 are exploratory or in-development. A dashboard showing only tier-1 failures is the one an on-call engineer checks first when something breaks. A dashboard showing tier-3 failures is one a developer reviews when building new models.

The right grouping depends on who’s looking. Engineers care about criticality. Business stakeholders care about their domain. Design the dashboard for its audience rather than for completeness.

Tagging is what makes filtering possible

Tags in your test definitions are what allow any of this filtering to work. Apply them deliberately:

tests:
  - elementary.volume_anomalies:
      tags: ['critical', 'finance', 'daily-check']
      meta:
        owner: 'analytics-team'

Then filter reports by tag:

edr report --select tag:critical

Or build BI dashboards that filter elementary_test_results by the tags column.

Tags only work if they’re consistent. A finance tag applied to 60% of finance models and missing from 40% produces a filtered dashboard with unexplained gaps. Establish a tag vocabulary before you start applying them, enforce it in code review, and check for gaps during quarterly reviews. The dbt Test Alert Routing and Ownership note covers a related pattern for routing alerts based on the same metadata.

Refresh frequency should match data update cadence

There’s no value in refreshing a report more often than your data actually changes.

Production reports should generate after each dbt run, so failures surface as soon as they occur. If dbt runs hourly, generate the Elementary report hourly. If it runs once a day, daily is fine.

Executive dashboards work better as daily rollups. An executive checking a data quality dashboard at 9 AM doesn’t need second-by-second updates — they need a clear picture of health over the last 24 hours. Hourly noise in a summary dashboard distracts more than it informs.

Development and ad-hoc reports are on-demand. Generate them when you need to review a specific model or investigate a specific failure, skip them when you don’t. Automating development reports in CI often creates noise without value — a test failure in a feature branch is expected and doesn’t need to show up in a shared report.

The --days-back flag for managing report scope

Elementary’s incremental models retain history indefinitely by default, which is what you want for long-term trend analysis. But reports that render months of data get slow and hard to read.

Use --days-back to limit what each report shows without losing the underlying history:

# Quick daily report (7 days)
edr report --days-back 7 --file-path ./reports/daily.html

# Monthly trend report (30 days)
edr report --days-back 30 --file-path ./reports/monthly.html

The full history stays in your warehouse tables and remains available for BI dashboards and ad hoc queries whenever you need it. The flag only controls what the HTML report renders, not what gets stored.

For long-term trend analysis — answering “is our data quality better than it was six months ago?” — query elementary_test_results directly rather than relying on the HTML report. The BI dashboard approach gives you full control over the time window and the aggregation method.