> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/observability-model.md).

# Observability

Monitoring in DataOS is organized across three layers that align with how the platform is structured. Each role monitors a different layer based on what they own or operate. This page explains the layers once, while the per-role Monitoring pages explain what each role needs to monitor and act on.

| Layer           | What it covers                                                           | Who watches it                            |
| --------------- | ------------------------------------------------------------------------ | ----------------------------------------- |
| DataOS Instance | Health of platform services (the System Health dashboard)                | Operator                                  |
| Data Plane      | Data Product workload execution, Compute health, Tenant runtime services | Operator, Tenant Admin                    |
| Data Product    | Runs, schedules, quality, freshness, and usage of a deployed product     | Developer (owns), Consumer (judges trust) |

This follows the same principle as the access model: each role sees the health and status information that is relevant to what they own or operate. Operators monitor whether the planes and platform services are running. Tenant Admins monitor the health of Tenant Compute and resources. Developers monitor their product runs, quality, and operational status. Consumers review the published trust information to decide whether they can rely on a Data Product.

## Instance health

The System Health dashboard is the first place to check whether Instance services are running, slow, or failing. It checks Instance endpoints and shows service availability, response time, certificate validity, and recent pass/fail history.

You can access the status dashboard from your Instance FQDN at `/status/`, for example: `https://<instance-fqdn>/status/`.

The dashboard shows each service as **Healthy**, **Degraded**, or **Down**.

* **Healthy** means the service is working as expected.
* **Degraded** means the service is reachable but may be slow or unstable.
* **Down** means the service has failed multiple checks in a row.

## Data Plane health

Data Plane Data Product workload and Compute health is monitored through the Operations application and Data Plane observability.

This helps Tenant Admins check whether Data Product workloads are scheduling correctly, Compute resources are healthy, Tenant runtime services are running, and the Tenant has enough capacity to support active Data Product workloads.

## Data Product health

A deployed Data Product reports its own operational health and status information, such as run history and status, schedule adherence, quality-check results, freshness, and usage.

The developer who owns the product monitors this information to catch failures, delays, and drift. The consumer reviews the published product information, such as quality, freshness, lineage, and run history, to decide whether they can trust and use the product.

Product-level trust information is available in the Data Product Hub and is covered in [Trust and freshness](https://v2.dataos.info/consume/evaluate/trust-and-freshness) in the Consume guide.

## Where each role uses this

* [Operator Monitoring](/operate/dataos-operator/monitoring.md): Monitors Instance health, platform services, and overall Data Plane availability.
* [Tenant Admin Monitoring](/operate/tenant-admin/monitoring.md): Monitors Tenant Compute, Data Product workload scheduling, runtime services, and resource capacity within the Tenant.
* [Data Admin Monitoring](/operate/data-admin/monitoring.md): Monitors Lakehouse health, data resource usage, and data availability.
* [Developer Operate your product](/operate/data-developer/operate-your-product.md): Monitors product runs, failures, schedules, freshness, and quality checks for the Data Products they own.
* [Consumer Trust and monitor](/operate/data-consumer/trust-and-monitor.md): Reviews published product information, including quality, freshness, lineage, and run history, before relying on a Data Product.


---

# 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://v2.dataos.info/operate/observability-model.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.