The first task each day is to confirm that the core OpenShift control plane and worker infrastructure are healthy. This review can usually be completed entirely through the OpenShift web console.
Cluster operators are healthy
Nodes are ready and available
MachineConfigPools are stable
Core platform services are functioning
No active platform issue is likely to block VM, storage, or application operations
Cluster operators are healthy
Nodes are ready and available
MachineConfigPools are stable
Core platform services are functioning
No active platform issue is likely to block VM, storage, or application operations
- Log in to the OpenShift web console.
- Open Home > Overview.
- Review the top-level status cards for cluster health, alerts, and operator state.
- If alerts are present, note whether they are informational, warning, or critical before proceeding.
- Navigate to Administration > Cluster Setting > Cluster Operators.
- Review the list of cluster operators and confirm: Status is Available , unless a planned change is currently underway.
- Pay particular attention to these operators: authentication, console, dns, etcd, ingress, kube-apiserver, machine-config, monitoring, network.
- Navigate to Compute > Nodes.
- Confirm that all expected control plane and worker nodes are in the Ready state.
- Open any node that looks abnormal and review its conditions, recent events, and allocated resources.
- Navigate to Compute > MachineConfigPools.
- Confirm the worker pool and any custom pools show: Update status as Up to date
- Navigate to Workloads > Pods. Filter on key platform namespaces and confirm there are no obvious failing or pending pods in: openshift-ingress, openshift-monitoring, openshift-machine-config-operator, openshift-authentication, openshift-console.
- Review restart counts for platform pods and investigate if a core service shows repeated restarts.
Essential daily checks
A daily cluster review does not need to become a long audit. At minimum, administrators should confirm:
| Check | Expected |
| All critical cluster operators are healthy | Pass |
| All expected nodes are in Ready state | Pass |
| No MachineConfigPool is degraded or unexpectedly updating | Pass |
| No core platform pods are failing repeatedly | Pass |
| Console remains responsive and usable | Pass |
What to review first when cluster health is degraded
When cluster health is degraded, start with the component most likely to narrow the problem quickly.
Start with cluster operatorsIf a cluster operator is degraded, open the operator and review the message and condition details first. In many cases, this immediately tells you whether the issue is related to authentication, routing, monitoring, certificates, node configuration, or the control plane itself.
Check nodes
If multiple nodes are NotReady, the issue may be infrastructure-related rather than application-related. This could point to host maintenance, network failure, DNS problems, certificate issues, or operating system configuration drift.
If only a subset of worker nodes is affected, check whether those nodes are also storage-capable nodes. If they are, continue quickly into the Portworx and FlashArray checks in the next sections.
Check MachineConfigPools
A degraded or stuck MachineConfigPool often indicates that a host-level change did not complete cleanly. This is especially important in environments using FC or iSCSI where storage-related services, kernel modules, or multipath settings may depend on worker configuration consistency.
Check platform pods and events
If operators are degraded but nodes are healthy, inspect pods and events in the relevant namespace. A platform service may be failing to start, repeatedly restarting, or unable to reconcile.