> ## Documentation Index > Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL. > Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other. > Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking. > Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify. # Cluster Status and Health > Interpret cluster status, admin state, member node readiness, and health signals in Edge Infrastructure Services. Use cluster status and health information to determine whether a cluster is ready for workloads, needs attention, or is still completing a lifecycle operation. Cluster status is the first signal, but member node readiness, admin state, and notifications together give the complete picture. ## Start from the Clusters List Open **Infrastructure > Fleet > Clusters**. The list shows each cluster with its name, **Status**, member count, project, and age. Use the **Status** filter to narrow the list to clusters in a particular state. If your enterprise has at least one cluster running in ZEDEDA Edge Kubernetes Service mode, the list also shows a **Mode** column (**Edge Node Cluster**, **K8s Cluster**, or **Imported K8s Cluster**) and a matching **Mode** filter. A cluster that uses two-node HA with a witness shows a **Two-node HA** badge in the **Mode** column. Its **Status** column shows the HA state instead of the run state once the controller reports one. ## Separate the Signals Status, admin state, node readiness, and notifications answer different questions. | Signal | What it tells you | Where to check | | - | - | - | | Status | The cluster's current operational run state. | Cluster list and detail page ribbon | | Admin state | Whether the cluster is administratively active, inactive, or in transition. | Cluster detail page ribbon | | Member node readiness | Whether each member node is healthy and accepting workloads. | Cluster detail **Nodes** tab and **Overview** topology tile | | Notifications | Errors, warnings, and notices reported by EVE-OS (Edge Virtualization Engine) for the cluster. | Notifications bell in the detail page header | | Two-node HA state | Quorum health of a two-node HA cluster, including the witness and per-node recovery. | Cluster list **Status** column and the **Two-node HA** panel on the **Overview** tab | | EVE-OS upgrade status | Progress or failure of an EVE-OS upgrade applied to the cluster. | Banner on the detail page when an upgrade is in progress | ## Interpret Cluster Status The **Status** field shown in the cluster list and on the detail page ribbon reflects the cluster's operational run state. The cluster list and the detail page use the same label and the same color for a given run state. | Status | Color | Meaning | Usual next check | | - | - | - | - | | Online | Green | The cluster is reachable and healthy. | Confirm member node readiness and application health. | | Provisioned | Blue | The cluster completed provisioning and is coming into service. | Wait for the status to reach Online, then confirm member node readiness. | | Provisioning | Amber | The cluster is initializing or completing setup. | Wait for provisioning to complete, then confirm the status updates to Online. | | Unprovisioned | Purple | The cluster record exists but the cluster has not been provisioned yet. For an imported Kubernetes cluster, this means you have not yet run the registration commands. | For an imported cluster, run the registration commands from the cluster detail page. For other clusters, confirm that member nodes are online. | | Partially Healthy | Amber | Some, but not all, of the cluster is healthy. | Review the **Nodes** tab for Not Ready members and open notifications. | | Unhealthy | Amber | The cluster is reachable but reporting an unhealthy state. | Review the **Nodes** tab, open notifications, and inspect member node health. | | Suspect | Amber | The cluster is reachable but behaving unexpectedly. | Review the **Nodes** tab for Not Ready members, open notifications, and check recent events. | | Error | Red | The cluster has entered an error state. | Open notifications for the error message, review the **Nodes** tab, and inspect member node health. | | Offline | Red | The cluster is not reachable. | Verify that member nodes are powered on and connected. Check each node's status under **Infrastructure > Fleet > Nodes**. | | Halted | Grey | The cluster is halted. | Confirm that the halt was intentional and check the admin state. | | None | Grey | The cluster has not reported a run state. | Wait for member nodes to report. If the state persists, check node connectivity. | Any run state that is not in the preceding table appears with its name formatted for display and a grey indicator. If no run state data is available, the Status field shows a dash. This typically occurs when a cluster was just created and member nodes have not yet reported their state. ## Interpret Two-Node HA State On a cluster that uses two-node HA with a witness, the HA state replaces the run state in the cluster list **Status** column. The **Two-node HA** panel on the cluster **Overview** tab shows the same state with the witness status, recovery generation, and per-node recovery rows. See [Manage Two-Node HA](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/manage-node-clusters.md#manage-two-node-ha). | HA state | Color | Meaning | Usual next check | | - | - | - | - | | Healthy | Green | Both nodes are Ready and online, and the witness joined at the configured address. | No action needed. | | Restoring | Blue | Membership, readiness, or the witness has not finished converging. | Wait, then review the **Witness** field and the **Node recovery** rows. | | Degraded | Red | One node is hosting etcd and the witness. The cluster has no redundancy until you add a replacement node. | Replace the failed non-seed node, or reset the quorum if the seed failed permanently. | | Unknown | Amber | Cluster information is stale while members remain reachable, so health cannot be trusted. | Wait for fresh status. Check node connectivity if the state persists. | | Unreachable | Amber | No cluster member is reachable from the controller. This is a connectivity problem, not necessarily a quorum problem. | Verify node power and connectivity before you consider a quorum reset. | A cluster can report **Degraded** while both nodes are still configured members, for example when only one node reports Ready. The **no physical redundancy** banner appears only when the cluster has one configured node, which happens after a quorum reset. A cluster keeps its **Two-node HA** badge while it runs on one node. The **Witness** field shows **Pending** until the node reports that the witness joined the configured address. After a quorum reset, the configured witness address changes, so the witness shows **Pending** until the surviving node reports the new address. ## Interpret Admin State The admin state appears as a secondary label in the cluster ribbon. It reflects the cluster's administrative lifecycle and is separate from the operational run state shown in Status. | Admin state | Meaning | | - | - | | Active | The cluster is administratively enabled and operational. | | Registered | The cluster is registered but not yet activated. | | Inactive | The cluster is administratively disabled. | | Deleting | A deletion is in progress. | | Created | The cluster record exists but activation has not started. | | Deleted | The cluster has been deleted. | | Unknown | The admin state cannot be determined. | ## Review the Cluster Overview Open a cluster from the list to see a detailed health view. The **Overview** tab is the default landing view and provides a snapshot across the following areas. | Area | What to inspect | | - | - | | Cluster ribbon | Status, member count (for example, 2/3 ready), last updated, type, project, and applications. | | Cluster topology | Ready, Not Ready, and Unspecified member counts, plus role breakdown (Server, Agent, Tie Breaker). Use this tile to identify how many nodes are currently healthy. | | Identity | Confirm admin state is **Active** and run state reflects the expected status. Verify that the project assignment is correct. | | Workloads | Check whether applications are present and whether any show a non-Online run state. | Move to the **Nodes** tab when the topology tile shows Not Ready members. Move to the **Applications** tab when workloads are not running as expected. For a full description of each tab and its fields, see [Manage Clusters](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/manage-node-clusters.md#view-clusters). ## Interpret Member Node Readiness The **Nodes** tab and the cluster topology tile surface member node readiness. Readiness is a Kubernetes-level signal that reflects whether each node is healthy from the cluster's perspective, independent of its EVE-OS-level status. | Readiness | Indicator | Meaning | | - | - | - | | Ready | Green | The node is healthy and accepts workload scheduling. | | Scheduling Disabled | Amber | The node is cordoned. It is reachable but will not accept new workload pods. | | Not Ready | Red | The node is unhealthy and does not accept workload scheduling. | | Unspecified | Muted | The node has not reported readiness data yet. | A Ready node might also report secondary conditions that appear alongside the primary readiness label. These indicate resource pressure that has not taken the node offline. | Secondary condition | Meaning | | - | - | | Memory Pressure | The node has insufficient available memory. | | Disk Pressure | The node has insufficient available disk space. | | PID Pressure | The node has too many running processes. | | Network Unavailable | The node's network configuration is incorrect or unavailable. | For example, a node can show **Ready, Disk Pressure**, which means it is accepting workloads but is approaching a resource limit that might affect future scheduling. ## Review Health Signals ### Notifications The **Notifications** bell appears in the cluster detail page header. A color-coded badge on the bell shows the count and highest severity: * Red badge: one or more errors are present. * Amber badge: one or more warnings are present, no errors. * Blue badge: one or more notices are present, no errors or warnings. When no notifications are present, the panel shows **All clear**. Select the bell to view each notification with its severity, explanation, and suggested fix. Notifications come from the cluster's EVE-OS error information and use the same structure as node notifications. ### EVE-OS upgrade banner When an EVE-OS upgrade is in progress or has completed, a banner appears on the cluster detail page. The banner color reflects the upgrade status. | Banner color | Meaning | | - | - | | Amber | The upgrade is in progress (downloading, upgrading, installing, or pending). | | Green | The upgrade completed successfully. | | Red | The upgrade failed or encountered an error. | If the banner shows red, open notifications for the specific error message. ## Readiness Checklist A cluster is generally ready for workloads when: * Status is **Online**. * Admin state is **Active**. * The topology tile shows all members as **Ready** with no secondary conditions. * No errors or warnings appear in the notifications panel. * Applications on the cluster are in an **Online** run state. * No EVE-OS upgrade is in progress. ## Troubleshoot by Symptom | Symptom | What to check first | | - | - | | Cluster is **Offline** | Verify that member nodes are powered on and reachable. Check each node's status under **Infrastructure > Fleet > Nodes**. | | Cluster is **Suspect** or **Error** | Open notifications on the cluster detail page. Review the **Nodes** tab for Not Ready members and inspect those nodes individually. | | Cluster shows **Provisioning** for an extended period | Confirm that all member nodes are online and that the cluster network interface is correctly configured on each node. | | Cluster shows **Unprovisioned** | For an imported Kubernetes cluster, run the registration commands from the cluster detail page. For other clusters, confirm that all member nodes are online and reporting. | | One or more members show **Not Ready** | Open the **Nodes** tab and review the readiness conditions on affected nodes. Check the corresponding node detail pages for EVE-OS errors or resource pressure. | | Members show secondary conditions (Disk Pressure, Memory Pressure) | Address the resource constraint on the affected node. Secondary conditions that persist might eventually cause the node to transition to Not Ready. | | Applications are not running on the cluster | Check the **Applications** tab for application run states. Verify that all member nodes are Ready. Review the **Virtual Interfaces** tab for network issues. | | Two-node HA cluster shows **Degraded** | Open the **Two-node HA** panel and the **Nodes** tab. Replace the failed non-seed node, or reset the quorum if the seed node failed permanently. | | Two-node HA cluster shows **Unreachable** | Verify that the nodes are powered on and connected. Do not reset the quorum to fix a connectivity problem. | | EVE-OS upgrade banner shows red | Open notifications for the specific error message. Verify the upgrade status with `zcli edge-node-cluster show --upgrade`. | ## Next Steps > [card] [Manage Clusters](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/manage-node-clusters.md) > > Operations such as update, replace a node, and delete. > [card] [App Instance Failover in Clusters](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/node-cluster-failover.md) > > Understand how applications behave during node failures. > [card] [Node Status and Health](https://zededa.mintlify.site/new-ui/infrastructure-services/nodes/node-status-and-health.md) > > Interpret the health of individual member nodes. > [card] [Upgrade EVE-OS on a Cluster](https://zededa.mintlify.site/new-ui/infrastructure-services/node-clusters/manage-node-clusters.md#upgrade-eve-os-on-a-cluster) > > Upgrade EVE-OS on a cluster with ZCLI.