> For the complete documentation index, see [llms.txt](https://docs.nodeum.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nodeum.io/data-mover/console/dashboard.md).
# Dashboard
### **Overview**
Health Check (nodeum.metric) continuously checks whether the components expected in your Nodeum Data Mover environment are actually running. The check runs every 30 seconds and compares the expected installation recorded by the installer with the current state of Nodeum services, databases, and cluster nodes.
The result is available from the Dashboard and is retained in MongoDB for 90 days.
Each monitored item is reported as Healthy, Degraded, Down, or Unknown.
### Dashboard
The Dashboard provides two health-related cards: Cluster Health and Health History. The screenshot below shows the health information available to administrators.
#### Cluster Health
The Cluster Health card shows the current state of the Data Mover environment.
* Overall cluster state — a summary such as Healthy.
* Service and database counts — each row shows how many expected components are currently healthy, for example 9/6 or 12/12 as displayed by the interface.
* Node status — node badges indicate whether each registered node is Up or Down.
* Component status — each row is assigned a health state and can provide a human-readable reason.
#### Health History
The Health History card displays the health timeline for the selected period and records incidents or periods where the health state changed.
* Use the time-range controls to review recent or historical health information.
* The timeline distinguishes healthy, degraded, down, unknown, and unchecked/no-history periods.
* Incident entries include the time and the reason reported by the health check.
* Health results are retained for 90 days.
#### Health Statuses
| Status | Description |
| -------- | --------------------------------------------------------------------------------------------------------------------- |
| Healthy | The component is running and matches the expected configuration. |
| Degraded | The component is not fully healthy, but the condition has not reached the Down state. |
| Down | The health check has determined that the expected component is not running or cannot be reached. |
| Unknown | The health check cannot determine the expected or current state, or there is insufficient information to evaluate it. |
#### What Is Checked
The health check compares the expected installation with the live environment.
| Area | Examples |
| --------------------------------- | ------------------------------------------------------------------------- |
| Nodeum services | Mover, Dispatcher... |
| Databases and supporting services | MariaDB, MongoDB, etcd, Redis, Sentinel, and other registered components. |
| Cluster nodes | Registered nodes and whether they are currently Online or offline. |
#### TLS and Authentication
Health checks support environments where strict TLS and authorization are enabled. The health-check component uses the appropriate authenticated connection for each dependency.
### Prometheus Metrics
The same health result is exposed through the existing /metrics endpoint for monitoring and alerting with Prometheus. Metrics use the prefix:
`nodeum_dm_cluster_health_*`
The exported metrics cover the cluster health status, health by system, running versus expected components, node state, and stale-result information. The values are read from the saved health result rather than recalculated independently by each server.
| Metric area | Purpose |
| ------------------- | ------------------------------------------------------------------ |
| Status | Overall cluster health state. |
| Per system | Health state for individual systems/components. |
| Running vs expected | Compares the number of running components with the expected setup. |
| Nodes | Reports node health/state. |
| Stale | Indicates whether the saved health result is stale. |
#### When a Component Is Not Healthy
* Start with the Cluster Health card and identify the affected row.
* Read the plain-language cause shown for the component.
* Check Health History to see whether the condition is new, persistent, or recurring.
* For an Unknown state, verify that the expected configuration is available and that the health-check component can access the required information.
* For Down or Degraded states, verify the affected service, database, or node and its network/TLS configuration.
* Remember that brief restarts may not immediately change the displayed state because health evaluation is intentionally delayed.
---
# 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://docs.nodeum.io/data-mover/console/dashboard.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.
