Risk propagation
Risk isn't only where the failure is — it's everywhere that depends on the failure. On every refresh, the ClusterMirror seeds each component with an intrinsic risk from its current state, then propagates a decayed share of it along the dependency edges.
This static illustration provides a quick visual summary of the same flow:
Intrinsic risk
The base risk a component starts with, by its current state:
| Condition | Base risk |
|---|---|
Lost PVC | 90 (Critical) |
| Workload Down / Failed | 70 (High) |
| Node NotReady | 60 |
Pending PVC | 50 |
| Workload Degraded (some replicas not ready) | 40 |
| Scaled-to-zero workload | 10 |
Services, Ingresses and config don't fail on their own — they only inherit risk from what they depend on.
Add-ons carry no risk in the ClusterMirror: it has no target version to check them against. Upgrade analysis gives them one.
Decay along edges
A dependent inherits the highest risk it depends on, multiplied by a decay factor per hop (default 0.6):
inherited = max(dependency risks) × 0.6^hops
So a Lost PVC (90) gives its direct dependent 90 × 0.6 = 54, the next hop 90 × 0.36 ≈ 32, and so on. Risk fades with distance but never disappears while a chain exists.
A component whose risk is ≥ 50 is flagged at risk, and counts in its namespace's at-risk total.
Risk shows where to look — it never blocks
This is the key distinction:
- Propagated risk colors the graph and adds up per namespace. It tells you where impact concentrates — and on its own it never blocks anything.
- A deploy is blocked only when the change itself breaks a dependency — deleting a Service an Ingress routes to, mounting a PVC that is
Pending— never because a namespace's risk is high. - An upgrade has its own gate, in upgrade analysis.
In other words: the graph shows you the blast radius; the gates decide whether to stop.
Per-namespace risk
The ClusterMirror rolls component risk up to a per-namespace view (status.byNamespace): each namespace's riskiest component, and how many components are at risk. It's where risk sits right now, worst first — on the Web UI's Cluster Mirror page, in kubectl get clustermirror, and in a pipeline with mirops scan -n.
Next
- See what a deploy is blocked on in the impact check.
- See what upgrade analysis adds on the same graph in upgrade analysis.