Skip to content
ENExplore Calculators

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

  1. 1Values used
  2. 2OpenShift Cluster Health
  3. 3Cluster Health Score= 95 / 100
  4. 4Health Grade= A — Excellent
  5. 5Node Readiness= 100.0
  6. 6Pod Health= 99.1
  7. 7etcd Latency Reading= Acceptable but close to the 10 ms threshold
  8. 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.

OpenShift Cluster Health Calculator | Calcrivo