The Elementary HTML report packs a lot into a single file. Understanding what each section is for helps you navigate to the right place depending on whether you’re doing a routine check, investigating a specific failure, or looking for performance problems.
Data health review
The homepage of the report. It shows total test count, pass/fail/warn breakdown, and test failures plotted over time. This is the right starting point for a routine daily or weekly review — a quick look at whether things are trending better or worse before diving into specifics.
The anomaly detection summary on this page highlights statistical outliers Elementary caught automatically, separate from your explicitly defined tests. Model run status gives you a quick view of execution health across your entire project.
A flat trend line with a stable pass rate indicates no new issues. A spike in failures or a downward trend in pass rate warrants drilling into the test results section.
Test results
Each test has its own detailed view with execution history, the test description, and its configuration. This section is where you do actual debugging.
When a test fails, you get three pieces of information that matter:
- The compiled SQL, which you can run directly against your warehouse to understand what the test is checking and why it’s failing
- Failed row samples (unless disabled with
--disable-samplesfor PII reasons) - The historical pass/fail pattern for that specific test
The time-series view in the test results section is particularly useful for distinguishing one-off failures from recurring problems. A test that failed once six weeks ago and has been passing since is different from one that fails every Monday. The time-series makes that pattern immediately visible in a way that log files don’t.
Model runtime tracking
Execution duration charts for each model, showing performance trends over time. This section catches something test results never will: models that are gradually getting slower.
A model that ran in 30 seconds three months ago and now takes 4 minutes hasn’t broken any tests. No alert fires. But it’s a sign that something is accumulating — whether that’s data volume, inefficient query plans, or a schema change that disabled partition pruning. The runtime tracking section surfaces these trends before they become outages.
Beyond execution time, you get bytes billed and rows affected for each run. This makes the model runtime section useful for BigQuery Cost Optimization work: you can identify which models are the most expensive to run and track whether optimization changes actually reduced cost.
Anomaly detection
For Elementary anomaly tests (volume_anomalies, freshness_anomalies, column_anomalies), this section shows time-series charts of the actual metric values plotted against expected ranges.
The visualization distinguishes between two periods:
- The training period, where Elementary established its baseline from historical data
- The detection period, where current values are compared against that baseline
When a metric crosses outside the expected range, that’s what triggers an anomaly failure. Seeing the chart makes it much clearer whether a failure is a genuine outlier or whether the baseline itself needs recalibration. A model with highly seasonal data might show “anomalies” that are actually just weekend traffic patterns — the chart makes this obvious, whereas the raw alert message doesn’t.
Column-level tracking displays each monitored metric (null rate, average, min, max, distinct count) separately, so you can see which specific metric drove the anomaly detection failure.
Lineage
The lineage view shows end-to-end data flow from your dbt manifest, with test coverage overlaid. When a test fails, the lineage view answers “what does this break?”
For analytics teams, lineage is most useful during incident response. A failure in a base model might cascade through intermediate models into a mart that powers executive dashboards. Seeing the full downstream impact before starting remediation helps you communicate urgency accurately — “this breaks the revenue dashboard” is different from “this affects a rarely-used internal table.”
Test coverage overlaid on lineage also reveals gaps. Models with no tests appear visually in the lineage view without any coverage indicators, which makes it easy to spot blind spots that might otherwise be invisible in a flat list of test results.