> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Observability Dashboard — Data

> How to read the Data tab of the Observability Analytics dashboard — uptime tiles, alert/issue heatmaps, schema changes, and unhealthy assets.

<script type="application/ld+json">
  {`{
              "@context": "https://schema.org",
              "@type": "TechArticle",
              "headline": "Observability Dashboard — Data",
              "description": "How to read the Data tab of the Observability Analytics dashboard — uptime tiles, alert/issue heatmaps, schema changes, and unhealthy assets.",
              "url": "https://docs.dqlabs.ai/architecture/observability-data-dashboard",
              "publisher": {
                "@type": "Organization",
                "name": "DQLabs Inc",
                "logo": "https://media.brand.dev/332adc35-5bc4-4d2b-bf78-256aa4a5e414.svg"
              }
              }`}
</script>

The **Data** tab of the Observability Dashboard gives an organization-wide view of data reliability: how often assets are fresh, how often volume behaves as expected, how often schemas stay stable, and which assets are currently unhealthy. Navigate to **Analytics → Observability (Data) → Data** to access it.

<Note>
  Observability is a separate signal from Quality: Quality scores *correctness* (DQ measures), Observability tracks *reliability* (did data arrive on time, in the expected volume, with the expected schema). An asset can be observability-healthy and still fail quality checks, or vice versa.
</Note>

## AI Summary

An AI-generated summary states the headline reliability figures for the current date range. In validation, this summary did not always refresh immediately when switching between the Catalog, Data, Pipeline, and Report tabs — it can briefly keep showing the previous tab's text. If the summary's wording doesn't match the tab you're looking at, give it a moment or treat the tiles and widgets below as authoritative.

## KPI cards

### Uptime tiles

| Card | What it shows | How it's calculated |
| :- | :- | :- |
| **Freshness Uptime** | % of the date range where in-scope assets updated on schedule | Time spent "fresh" ÷ total time in range, averaged across in-scope assets |
| **Volume Uptime** | % of the date range where ingested volume was within the expected band | Time spent "normal volume" ÷ total time in range |
| **Schema Uptime** | % of the date range where schema stayed stable (no breaking/unexpected change) | Time spent "stable schema" ÷ total time in range |

Each uptime tile compares against a **100.00% prior 90d** baseline — the previous period is treated as a perfect baseline for comparison purposes rather than its own measured value.

### Count tiles

| Card | What it shows | How it's calculated |
| :- | :- | :- |
| **Stale Assets** | Count of assets currently flagged stale (not updated within their expected cadence) | A point-in-time count of assets whose freshness status is stale, filtered to scope |
| **Volume Anomalies** | Count of volume-anomaly events in the selected date range | A straight count of volume-anomaly events matching filters and date range |
| **Schema Changes** | Count of schema-change events in the selected date range | A straight count of schema-change events matching filters and date range |
| **Freshness Alerts** | Count of freshness-alert events in the selected date range | A straight count of freshness-alert events matching filters and date range |

<Warning>
  All seven tiles animate with a count-up effect and can take several seconds to settle after the page loads or after any filter/date/Slice By change. Read a tile only after two consecutive looks agree — in validation, a tile read mid-animation showed values several multiples off from the settled number.
</Warning>

## Widgets

### Alert heatmap

A heatmap of alert counts with **Domain** as rows and time buckets (controlled by **Slice By**) as columns, with sub-tabs for **Volume**, **Freshness**, and **Schema**. The legend runs **0-20 green → 80+ red**, because for alerts *higher is worse* — this is the inverse of the Quality Dashboard's score heatmaps, where green means a high (good) score.

### Issue heatmap

The same structure as the Alert heatmap — Domain rows, Slice-By time-bucket columns, Volume/Freshness/Schema sub-tabs, 0-20 green → 80+ red — but for issue counts instead of alert counts.

### Recent schema changes

A table of individual schema-change events at the **column** level (finer-grained than the Catalog Dashboard's asset-level Schema Changes widget). Columns: **Asset**, **Change Type** (e.g. Column Added), **Changed Field**, **Impact** (e.g. Additive), **Changed** (timestamp).

### Unhealthy assets

A table of assets with at least one reliability problem. Columns: **Asset**, **Data Updated** (last update timestamp), **Freshness** / **Volume** / **Schema** (per-dimension status, e.g. Stale / Normal / Stable), **Impacted Assets**, **Reports**, **Dashboards** (downstream BI impact counts via lineage).

## Filters

Same filter bar as the other Analytics dashboards: **Domain, Application, Product, Tag, Source, Asset Type, Asset, Date Range, Slice By, Previous Period**. See [Catalog Dashboard](/architecture/catalog-dashboard#filters) for the full list of options; the mechanism is identical here.

<Tip>
  Filter selections persist across page reloads and across navigating away and back, for as long as your session is active. Click **Reset** to confirm you're looking at the true unfiltered baseline before drawing conclusions from the numbers.
</Tip>

## Slice By: time-bucket granularity for the heatmaps

**Slice By** offers the same six options as elsewhere (Day, Week, Month, Quarter, Half-year, Year; defaults to **Week**). On this dashboard it rebuckets the column headers of the **Alert heatmap** and **Issue heatmap** — it does **not** change any KPI tile.

Worked example, no other filters applied:

| Slice By | Heatmap columns | Freshness Uptime | Volume Uptime | Schema Uptime |
| :- | :- | :- | :- | :- |
| Week | `Jul 20, Jul 27, Aug 10, ... Sep 28` (weekly points) | 99% | 98% | 98.910% |
| Month | `Jul 01, Aug 01, Sep 01, Oct 01` (4 monthly points) | 99% | 98% | 98.910% |

Only the heatmaps' column buckets changed — every KPI tile stayed identical, the same pattern documented for the Quality Dashboard's trend chart and heatmaps.

## With filter vs. without filter: a worked example

Example captured during validation, Last 90 days, no Slice By change:

| KPI | Without filter (all asset types) | With filter (Asset Type = `Table`) |
| :- | :- | :- |
| Freshness Uptime | 99% | 97.030% |
| Volume Uptime | 98% | 94.070% |
| Schema Uptime | 98.910% | 96.610% |
| Stale Assets | 1.132K | 202 |
| Volume Anomalies | 83 | 61 |
| Schema Changes | 24 | 17 |
| Freshness Alerts | 14 | 8 |

Narrowing to a single asset type reduces every count tile (fewer matching assets/events) and, in this snapshot, also reduced the uptime percentages slightly — tables in this environment had a somewhat worse reliability record than the full asset population over the period. The same mechanism applies to every other filter field and to combinations of them.

<Note>
  The exact figures above are an illustrative example and will not match your environment. The relationship they demonstrate — filtering narrows the population, Slice By only rebuckets time — is what to rely on, not the specific numbers.
</Note>

## Related pages

<CardGroup cols={2}>
  <Card title="Catalog Dashboard" icon="table" href="/architecture/catalog-dashboard">
    The Catalog tab of Analytics — asset discovery, classification coverage, and governance health
  </Card>

  <Card title="Quality Dashboard" icon="chart-line" href="/architecture/quality-dashboard">
    DQ score, alerts, and issues — the correctness counterpart to this reliability dashboard
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.