> 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 The layers of monitoring in DataOS, and which signals each role watches. Monitoring in DataOS is organized across three layers that align with how DataOS 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 Instance services (the Instance Status page) | 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 DataOS 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 [Instance Status page](/operate/instance-status.md) 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 it from your Instance FQDN at `/status/`, for example: `https:///status/`. The page reports each service as Healthy, Degraded, or Down. For what each status means, the endpoint groups, when to check the page, and what to do at each status, see [DataOS Instance Status](/operate/instance-status.md). ## 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, DataOS 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 Monitor Data Product](/operate/data-developer/monitor-data-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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://v2.dataos.info/operate/observability-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.