Service Mesh Health Score Calculator
Score overall service mesh health from success rate, p99 latency, error budget consumption and sidecar health into a single composite metric.
Inputs
Percent of requests through the mesh completing successfully.
Observed p99 latency across mesh traffic.
Target/SLO p99 latency ceiling.
Percent of the current period's error budget already consumed.
Percent of sidecars reporting healthy status (not crash-looping, synced config, passing readiness).
Service Mesh Health Score
83.3/ 100
Health Category
Healthy
Success Rate Score
99.5/ 100
Latency Score
64.0/ 100
Error Budget Score
70.0/ 100
Sidecar Health Score
98.0/ 100
Step by step
Latency score: (1 − p99/target) × 50 + 50, clamped
(1 − 180/250) × 50 + 50
= 64.0
Error budget score: 100 − consumed%
100 − 30
= 70.0
Composite: weighted sum of 4 sub-scores
99.5×0.3 + 64.0×0.2 + 70.0×0.3 + 98.0×0.2
= 83.3
How it works
This composite score combines four signals into a single mesh health indicator: success rate and error budget consumption (each 30% weight, since they're the clearest outcome measures of user-facing reliability), and p99 latency-vs-target and sidecar fleet health (each 20% weight, as supporting operational signals). Categories — Excellent (90+), Healthy (75-89), Degraded (50-74), Critical (under 50) — give an at-a-glance read on whether the mesh needs operational attention.
Formula
health_score = success_rate_score × 0.35 + latency_score × 0.25 + error_budget_score × 0.20 + mtls_coverage_score × 0.20
- success_rate_score
- Service success rate normalized to 0-100
- latency_score
- p99 latency score (lower is better, normalized)
- error_budget_score
- Remaining error budget normalized to 0-100
- mtls_coverage_score
- Percent of traffic covered by mTLS
Frequently Asked Questions
Why weight error budget consumption as heavily as success rate?
Success rate is a point-in-time snapshot, while error budget consumption reflects trend — a mesh with a currently-fine success rate but a rapidly depleting error budget is heading toward an SLO breach, so weighting both equally catches problems earlier than success rate alone.
How is the latency score calculated when p99 exceeds the target?
The score formula (1 − p99/target) × 50 + 50 drops below 50 once p99 exceeds target, and is clamped to 0 at 2x the target latency or worse — this rewards headroom below target and penalizes overages progressively rather than as a hard pass/fail cutoff.
What counts as an unhealthy sidecar?
Commonly: sidecars that are crash-looping, have stale/unsynced configuration from the control plane (e.g. Istio's proxy config version mismatch), or are failing their own readiness/liveness probes — any of these compromise the mesh's ability to route and secure traffic correctly through that pod.
Should this score replace dedicated SLO alerting?
No — this composite is meant as a quick operational dashboard summary, not a replacement for dedicated multi-window burn-rate alerting on each underlying metric, which catches fast-developing issues that a periodic composite score snapshot could miss.
You might also need
- Service Mesh Overhead CalculatorCommonly used together
- Retry Policy CalculatorCommonly used together
- Circuit Breaker Threshold CalculatorCommonly used together
- mTLS Performance CalculatorCommonly used together
- Platform Reliability Score CalculatorCommonly used together
- Timeout Configuration CalculatorAlso in Service Mesh & API Gateway