Skip to content
Calcrivo

Cluster Health Score Calculator

Generate an overall health score for a Kubernetes cluster from key operational metrics.

Inputs

nodes

Total number of nodes in the cluster.

nodes

Nodes reporting NotReady or under memory/disk pressure.

pods

Pods stuck in Pending state (unschedulable or waiting on resources).

restarts

Total pod restarts observed across the cluster in the recent window.

ms

etcd disk write / consensus latency (p99), a key cluster control-plane health signal.

Cluster Health Score

85.3

Health Status

Degraded

Unhealthy Node Penalty

1.5

Pending Pod Penalty

6.0

Restart Penalty

3.0

etcd Latency Penalty

4.2

Step by step

  1. Unhealthy node penalty

    (1/20) × 30

    = 1.5

  2. Pending pod penalty

    min(20, (3/10) × 20)

    = 6.0

  3. Restart penalty

    min(25, 15/5)

    = 3.0

  4. etcd latency penalty

    min(25, max(0, (25−10)/90×25))

    = 4.2

  5. Cluster health score

    100 − sum of penalties

    = 85.3 (Degraded)

How it works

This score starts at 100 and subtracts weighted penalties for four common cluster distress signals: the proportion of unhealthy nodes (up to 30 points), pending/unschedulable pods (up to 20 points), pod restart churn (up to 25 points), and elevated etcd latency, which signals control-plane stress (up to 25 points). Formula: health = 100 − unhealthy_node_penalty − pending_pod_penalty − restart_penalty − etcd_penalty. Scores map to Healthy (90+), Degraded (75-89), At Risk (50-74) or Critical (<50).

Formula

Cluster health score

health = 100 - (unhealthy_nodes / total_nodes) × 30 - min(20, pending_pods / 10 × 20) - min(25, restarts / 5) - min(25, max(0, (etcd_latency_ms - 10) / 90 × 25))

unhealthy_nodes
Nodes reporting NotReady or pressure
total_nodes
Total cluster nodes
pending_pods
Pods stuck in Pending state
restarts
Pod restart count in the window
etcd_latency_ms
etcd p99 write/consensus latency (ms)

Frequently Asked Questions

Why does etcd latency matter for overall cluster health?

etcd is the cluster's source of truth — the API server, scheduler and controllers all depend on fast etcd reads/writes. Elevated etcd latency (often from disk I/O contention or too many watchers) can cascade into slow scheduling, delayed reconciliation, and API timeouts cluster-wide.

What's a normal etcd latency?

Healthy etcd clusters typically see disk write / consensus latency (p99) under 10-25ms; sustained latency above 100ms is a strong signal of disk or network issues and often precedes broader cluster instability.

Why cap the pending-pod penalty at 20 points?

A handful of pending pods is often transient (waiting for a scale-up event) rather than a systemic issue, so the penalty scales linearly but is capped to avoid over-weighting a metric that self-resolves quickly compared to, say, persistent node failures.

Should pod restarts always be treated as bad?

Not always — some restarts are expected (rolling deploys, liveness probe recovery). This metric is best tracked as a rate/trend over a fixed window rather than a cumulative all-time count, so recalibrate the input to your chosen window.

You might also need