> For the complete documentation index, see [llms.txt](https://docs.soda.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.soda.io/soda-cloud-dashboards.md).

# Soda Cloud dashboards

Open Soda Cloud and see what matters to you.

{% hint style="info" %}
Dashboard views are currently available as a [**public beta** feature](/reference/documentation-access-and-licensing/release-stages.md#public-beta) at no additional cost during the beta.

To opt out, contact <support@soda.io>, or select **Back to the classic dashboards** in the top of the page. Soda will remember the choice in your browser. See [Organization dashboard](/soda-cloud-dashboards/organization-dashboard.md) for what the classic dashboard offers.
{% endhint %}

**A dashboard view** **summarizes** the **data quality results** Soda has collected across your estate. With the Soda Cloud dashboards, you can see the overall health of the **data quality that matters to you**, **grouping metrics** by your own attributes, building your own **customized views**, and accessing **trends over time**.

Soda Cloud ships with three views, each built around a different question:

* **Is quality improving?**
* **Is the data quality program working?**
* **What needs fixing today?**

<figure><img src="https://1123167021-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA2PmHkO5cBgeRPdiPPOG%2Fuploads%2Fc0cBlNl40OBkIBvS6u56%2Fimage.png?alt=media&amp;token=4e1a7985-562d-4191-8223-0bd40f891265" alt=""><figcaption></figcaption></figure>

Pick the view closest to your job and start there. **Every dashboard is customizable**: every tile can be moved, resized, duplicated, or removed, and opening a tile lets you rewrite its title and description and change the measure, the grouping, and the visualization behind it.

{% embed url="<https://www.youtube.com/watch?v=JZd2_8hWhzA>" %}
Watch customizable dashboards in action.
{% endembed %}

### Executive overview: the CDO cockpit

The **executive view** answers three questions a CDO gets asked in board and steering meetings:

* Is **quality getting better?**
* Is the **program reaching more** of the estate?
* How much of the estate has **an agreement behind it**?

<figure><img src="https://1123167021-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA2PmHkO5cBgeRPdiPPOG%2Fuploads%2F7ddN07IrPvsmsge1WKF9%2Fimage.png?alt=media&amp;token=8be517c5-9aba-44a4-bb51-6c287fbf22f7" alt=""><figcaption></figcaption></figure>

Use it when you need a number to report upwards, or when you want to see whether last quarter's investment moved anything. **Filter the board to one domain** (for example, a specific data source or dataset owner) and it becomes the same report for a **single business unit**.

### Manager overview: the state of the data quality program

The **manager view** sits between the executive summary and the daily detail. It keeps the **health** and **coverage** headlines, then adds the **operational picture** underneath:

* What is **running**?
* What is **failing**?
* What has **not been brought** into Soda yet?

<figure><img src="https://1123167021-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA2PmHkO5cBgeRPdiPPOG%2Fuploads%2F0fLVYzW6pPqfhzEzESKC%2Fimage.png?alt=media&amp;token=ec0c4aef-cc3f-489b-8637-d3dcc8fc29d4" alt=""><figcaption></figcaption></figure>

**DQ Health Score** and **Coverage** carry over from the executive view. The rest shows the state of your data quality program and where to push it next: check **outcomes** and [**anomalies**](/data-observability.md) over time, what's **onboarded** and what isn't, as well as health per dataset.

This is the view for **whoever owns the data quality program**: a **data quality lead**, a **governance lead**, or an **engineering manager** whose team is responsible for the pipelines. It answers where to put the next unit of effort, which is usually either a data source with a lot of failing checks, or a pile of discovered datasets nobody has onboarded.

### Steward overview: what to fix today

The **steward view** drops the estate-wide framing and shows the **working queue**:

* **Which datasets** have failing checks?
* **How many rows** passed and failed in each?
* **Where** are **anomalies** happening?

<figure><img src="https://1123167021-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FA2PmHkO5cBgeRPdiPPOG%2Fuploads%2FODlq1f2gf7D4JUVLBOX6%2Fimage.png?alt=media&amp;token=f6148a4e-a60d-4cac-aa59-442dffca351d" alt=""><figcaption></figcaption></figure>

Use the **steward overview** as the **start of a shift**. The datasets at the top of those bars are the ones worth opening first, and clicking through to the check takes you to the individual results.

### Custom overview: a dashboard just for you

You can customize any of the default dashboard overviews or build one from scratch to see what you care about at a glance.

> Learn more about how to [customize your dashboard](/soda-cloud-dashboards/customize-a-dashboard.md).

***

## Definitions of tile metrics

Every tile that reports a score uses one of the definitions below. **Hover the** <i class="fa-circle-info">:circle-info:</i> **icon** on a tile to see the same definition in the product.

### DQ Health Score

The percentage of checks that passed, out of all checks evaluated in the tile's time range.

A tile's time range is part of the tile, so two tiles showing a health score over different ranges will show different numbers for the same datasets. The default range is the last 90 days.

{% hint style="warning" %}
**The health score on a dashboard tile and the one on a dataset's Checks tab are not the same number.**

* The **dashboard tile** averages the score across the tile's time range, and leaves out checks that have never been evaluated.
* The **Checks tab** shows the score for the current state of the contract, and counts a never-evaluated check as not passing.

A dataset with two unevaluated checks can read 84% on a dashboard and 73% on its Checks tab at the same moment. Both are correct for what they measure.
{% endhint %}

### Coverage

The share of datasets that have data quality in place. A dataset counts as covered once it has at least one check, metric monitor, published contract, or data standard.

### Has Contracts

Datasets count as "With contract" once their contract is published. A draft doesn't count as a dataset with contract.

### Has Monitors

Monitored datasets have at least one metric monitor configured. The rest have none, so Soda isn't tracking their metrics for anomalies.

### Onboarding Status

* **Onboarded datasets** have been added to Soda, so Soda can scan and check them.
* **Discovered datasets** were found in the data source but aren't onboarded yet, so nothing runs on them.

{% hint style="info" %}
These formulas are fixed. You cannot yet define your own health score or coverage formula, or weight checks differently when they roll up.
{% endhint %}

***

## Dashboards outside Soda Cloud

If your organization already reports from Power BI, Tableau or Looker, **you can pull Soda's results** into those tools instead of building the view in Soda Cloud.

Two routes, depending on what you need:

* The [**Soda REST API**](/reference/soda-apis/rest-api.md) returns aggregate results: check outcomes, dataset metadata, and incidents. Use it for **the same numbers the dashboard tiles show, expressed in your own reporting model**.

- The [**Diagnostics Warehouse**](/diagnostics-warehouse.md) holds the rows behind a failing check. It runs in your own environment, so point a BI tool at it directly when you need record-level detail. Nothing at that level is available through the API, because failed rows are never stored in Soda Cloud.

***

## Limitations & edge cases

* Dashboards are updated **hourly**.
* Dashboards report on your data, not on your users. Active datasets and active checks are available as metrics, but **user activity is not**.

#### Public beta

**During public beta**, we are working to improve functionalities. For the time being, dashboard views have the following limitations to keep in mind:

* **Dashboard views are stored locally** in your browser, not in Soda Cloud. A view you build is only available in the browser you built it in, and clearing your browser data removes it.
* **Dashboard views cannot be shared** with other users.
* Dashboards can show historical data up to 90 days. However, during public beta, the **timeline will** **be limited to the date** **when dashboards were implemented** in your organization.\
  This means that, if the feature was introduced 25 days ago, dashboards will show data going back up to 25 days.

{% hint style="success" %}
Soon, dashboard views will be **shareable** and **persist** in your Soda Cloud account.
{% endhint %}

#### Record-level detail

* **Dashboard tiles aggregate results**. They do not show the rows behind a failing check, because failed rows are written to your [Diagnostics Warehouse](/diagnostics-warehouse.md), which runs inside your own environment and is never stored in Soda Cloud.

To analyze failed rows, query the Diagnostics Warehouse directly or point a BI tool at it.

***

{% hint style="info" %}
You are **not logged in to Soda** and are viewing the default public documentation. Learn more about [Licensing & documentation access](/reference/documentation-access-and-licensing.md).

If you do have a Soda license, make sure to **log in to Soda Cloud in this same browser**.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.soda.io/soda-cloud-dashboards.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.