# Quality Dashboard

The **Data Quality Dashboard** at `/data-quality` is the catalog's cross-entity quality view. It builds on top of the test results imported through the [Test Results Import](/features/data-quality/test-results-import.md) paths — Great Expectations, dbt, `odd-collector-profiler`, and custom frameworks — and renders them as one operator-friendly summary.

Quality checks are not performed inside ODD Platform — the dashboard surfaces results from the integrated tools.

![Data Quality dashboard — three pie charts at the top (Table Health 88 tables: 42 success / 28 failed / 18 broken; Test Results Breakdown 335 tests: 273 passed / 32 failed / 30 skipped; Monitored Tables 98: 87 monitored / 11 unmonitored) and a per-test-category matrix on the right showing per-anomaly-class counts. The left rail carries two filter sets — one for tables, one for tests.](/files/EQofrkQNtYBqeETc10M0)

## Three breakdown rings

The dashboard's hero row is three pie charts, each computed across the catalog at the time the page is loaded:

* **Table Health** — the count of tables broken down by their aggregate health status (success / failed / broken).
* **Test Results Breakdown** — the count of test runs broken down by status (passed / failed / skipped).
* **Monitored Tables** — the count of tables broken down by whether they are monitored (have at least one DQ test) or unmonitored.

The "Monitored vs Unmonitored" framing applies specifically to **Table-type datasets** — the catalog's primary tabular entities.

## Six anomaly-class metrics

The right-side matrix shows the breakdown of failures across the six anomaly classes the platform recognises. Each metric represents a dimension of data quality:

* **Assertion Tests** — validations or checks put in place to ensure that specific conditions or assertions about the data are met.
* **Column Values Anomalies** — irregularities or unexpected values in the data that deviate from a predefined set of acceptable or standard values.
* **Freshness Anomalies** — staleness signals — checking whether the data is up-to-date and falls within the acceptable time frame.
* **Schema Changes** — modifications in the structure or organization of the data, with a focus on monitoring whether the data schema remains consistent over time.
* **Unknown Category** — data placed into a category that was not foreseen or specified in the established data model or schema.
* **Volume Anomalies** — unexpected changes in the quantity or volume of data.

For each of these metrics the dashboard assigns statuses to the checks, distinguished by colors for better visualization:

<figure><img src="/files/H0rNv7knQVLfTspBkq5L" alt="" height="74" width="700"><figcaption><p>Checks Statuses distinguished by colors</p></figcaption></figure>

## Monitored vs unmonitored portions

Beyond the per-anomaly breakdown, the dashboard reports what portion of data was monitored and what portion was skipped:

<figure><img src="/files/CsEChWQ0Ts1tiBKis6z9" alt="" height="496" width="413"><figcaption><p>Monitored / unmonitored tables portions</p></figcaption></figure>

This applies specifically to Table-type datasets — the catalog's primary tabular entities.

## Filtering

Filter the dashboard by five dimensions: **Namespace**, **Datasource**, **Owner**, **Title**, and **Tag**. The filters apply on **two separate sides**:

* **Tables-side filters** — narrow the Table Health and Monitored Tables rings to the selected slice of tables.

<figure><img src="/files/JOX4ILqXH9EFzxbCdoeW" alt="" height="374" width="700"><figcaption><p>Filters for tables</p></figcaption></figure>

* **Tests-side filters** — narrow the Test Results Breakdown ring to tests with the selected attributes.

<figure><img src="/files/oacyDv4mOYw1pagPCqEH" alt="" height="385" width="700"><figcaption><p>Filters for tests</p></figcaption></figure>

The two filter sets are independent — you can hold the tables-side filter at one slice and the tests-side at another, which is useful when reasoning about test coverage across a slice of tables.

ODD users can narrow down test results for datasets by multiple attributes simultaneously.

<figure><img src="/files/NEhk28JqJTsxdrTuwBVh" alt="" height="460" width="700"><figcaption><p>Filtering by multiple attributes simultaneously</p></figcaption></figure>

{% hint style="info" %}
**`AND`-only conjunction.** For simplicity the platform implements only one logical conjunction across filter dimensions — `AND`. The results displayed after filtering are the outcome of all selected filters intersected together.
{% endhint %}

## Where to next

* [Test Results Import](/features/data-quality/test-results-import.md) — how the test results that populate the dashboard land in the catalog.
* [Dataset Quality Statuses (SLA)](/features/data-quality/sla-statuses.md) — operator-set severities on test results that feed the dataset-level SLA.
* [Alerting](/features/active-platform-features/alerting.md) — DQ-test-failed alerts feeding through the alert lifecycle.
* [Visibility for Data Quality Engineer](/use-cases/use-cases/dq-visibility.md) — the dashboard in the context of the DQ-engineer end-to-end workflow.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opendatadiscovery.org/features/data-quality/dashboard.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.