OpenShift Cluster Health Calculator
Score OpenShift cluster health from node readiness, pod failures, etcd fsync latency, API latency and degraded operators.
About OpenShift Cluster Health Calculator
The score is a weighted blend of the signals that actually predict an OpenShift outage. etcd fsync latency carries as much weight as node readiness because etcd is the single point of failure for the whole control plane — once fsync exceeds 10 ms the leader loses elections and every API call starts timing out, regardless of how healthy the workers look. Symptoms surface far from their cause in Kubernetes: slow etcd disks present as failing deployments, and a degraded operator presents as an upgrade that silently will not start. Scoring the signals together points at the layer that is actually broken.
Formula
OpenShift Cluster Health
score = node readiness × 0.25 + pod health × 0.20 + etcd latency score × 0.25 + API latency score × 0.15 + operator score × 0.10 + storage score × 0.05.
- etcd latency score
- Banded from 99th-percentile fsync: 100 under 5 ms, 80 under 10 ms
- operator score
- 100 minus 25 per degraded cluster operator
- node readiness
- Ready nodes as a share of total nodes
Worked example
With the default values below, OpenShift Cluster Health Calculator returns Cluster Health Score of 95. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Nodes in clusteraccepts 1–2,000 nodes
- 12 nodes
- Nodes not readyaccepts 0–2,000 nodes
- 0 nodes
- Pods scheduledaccepts 1–200,000 pods
- 640 pods
- Pods not running or readyaccepts 0–200,000 pods
- 6 pods
- etcd 99th percentile fsyncaccepts 0.1–500 ms
- 8 ms
- API server 99th percentile latencyaccepts 1–30,000 ms
- 180 ms
- Degraded cluster operatorsaccepts 0–40 operators
- 0 operators
- PersistentVolumeClaims pendingaccepts 0–100 %
- 1 %
Results
- Cluster Health Score
- 95 / 100
- Health Grade
- A — Excellent
- Node Readiness
- 100.0%
- Pod Health
- 99.1%
- etcd Latency Reading
- Acceptable but close to the 10 ms threshold
- Largest Contributing Risk
- etcd latency is the weakest signal at 80 out of 100
Step by step
- 1Values used
- 2OpenShift Cluster Health
- 3Cluster Health Score= 95 / 100
- 4Health Grade= A — Excellent
- 5Node Readiness= 100.0
- 6Pod Health= 99.1
- 7etcd Latency Reading= Acceptable but close to the 10 ms threshold
- 8Largest Contributing Risk= etcd latency is the weakest signal at 80 out of 100
Assumptions and limits
- The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is OpenShift Cluster Health calculated?
score = node readiness × 0.25 + pod health × 0.20 + etcd latency score × 0.25 + API latency score × 0.15 + operator score × 0.10 + storage score × 0.05. The score is a weighted blend of the signals that actually predict an OpenShift outage. etcd fsync latency carries as much weight as node readiness because etcd is the single point of failure for the whole control plane — once fsync exceeds 10 ms the leader loses elections and every API call starts timing out, regardless of how healthy the workers look.
Why does OpenShift Cluster Health matter?
Symptoms surface far from their cause in Kubernetes: slow etcd disks present as failing deployments, and a degraded operator presents as an upgrade that silently will not start. Scoring the signals together points at the layer that is actually broken.
What values do I need to enter?
This calculator takes 8 inputs: Nodes in cluster, Nodes not ready, Pods scheduled, Pods not running or ready, etcd 99th percentile fsync, API server 99th percentile latency, Degraded cluster operators, PersistentVolumeClaims pending. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why is etcd fsync weighted so heavily?
etcd must durably commit every write to its write-ahead log before acknowledging it, so fsync latency is the floor for every API write. Beyond 10 ms at the 99th percentile, heartbeats miss their deadlines and the cluster starts electing new leaders under normal load.
Related Calculators
You might also need
- OpenShift Node Capacity CalculatorCommonly used together
- OpenShift Pod Density CalculatorCommonly used together
- OpenShift Route Capacity CalculatorCommonly used together
- OpenShift Upgrade Time CalculatorCommonly used together
- Infrastructure Utilization CalculatorCommonly used together
- Hypervisor Consolidation CalculatorAlso in Virtualization & Private Cloud
