Upgrade Readiness

The Upgrade Readiness tab answers one question: if I take this cluster to the next minor, what breaks?

The layout is a ledger. A verdict strip and a six-gate strip stay pinned at the top; everything else lives behind five sub-tabs, so the page stays about one screen tall instead of a long scroll of cards.

The verdict

Verdict	Meaning
READY	Nothing blocking. Proceed.
REVIEW	Findings exist but none block. Read them, then decide.
NOT READY	At least one blocking finding. Fix before you hop.
INSUFFICIENT DATA	The scan could not see enough to answer. Not a pass.
SCANNING	Analysis in flight.

The distinction that matters is the last two against the first. INSUFFICIENT DATA is a deliberate refusal, not a green light — see Scan coverage below.

The six gates

Findings are grouped by failure mode, not by severity, because failure mode is what you plan around.

Gate	What lands here
Add-ons	Installed add-ons whose version has no support statement for the target minor. These break first, and they break hard.
Nodes & skew	Nodes and node components that would fall more than one minor behind the control plane after this hop, plus kubelet and container-runtime changes.
APIs & CRDs	Removed or deprecated API versions, CRDs and volume plugins that something in the cluster still submits.
Config & gates	Component flags, config-file fields and feature gates the target release removes. The API keeps working; the process does not start.
Dashboards	Metric and label renames in the path. Nothing crashes, but your dashboards and alert rules go quiet.
Workload hygiene	Workload-level hygiene, manifest-validation changes, and the remaining upgrade advisories.

The partition is total: every finding lands in exactly one gate, and the gate counts always sum back to the finding count. Workload hygiene is a deliberate catch-all rather than an “other” bucket that can be empty, so a newly published rule shows up somewhere instead of disappearing.

Scan coverage

This is the part most upgrade tools do not have, and the reason a clean result here means something.

Twelve detection tiers run independently:

deprecated-apis · crd-deprecations · node-skew · workload-ha · image-hygiene · runtime-deprecated-apis · plugin-removal · config-breakers · node-runtime · advisories · webhook-risk · addon-compat

Each reports its own status:

Tier status	What it means
RAN	Checked against current, non-stale data.
SKIPPED_NO_DATA	Could not run — never synced, disabled, or its own probe found no signal.
NOT_ASSESSED	Emitted an explicit “not assessed” marker: a provider-managed control plane, an uninspectable node fact. A stated verdict, never a silent clean.
PARTIAL	Ran on one data surface but a disjoint one was unreachable — e.g. kubelet config assessed, control-plane static-pod flags not.
STALE	The underlying inventory is older than the staleness threshold.
ERROR	The check threw while evaluating.

Those roll up into the scan status, first match wins:

1. INSUFFICIENT_DATA — the cluster never synced.
2. STALE — inventory older than the threshold (15 minutes by default).
3. PARTIAL — any tier skipped, not assessed, partial, or errored.
4. COMPLETE — every tier ran.

Why this exists

A swallowed database error looks exactly like a healthy cluster: zero findings. The six inventory-sourced tiers use a dedicated tri-state probe that distinguishes a query failure from a genuinely empty result, so an outage behind them reports ERROR rather than a silent RAN. An unreadable or wholly empty core inventory escalates straight to INSUFFICIENT_DATA — it can never present as a green COMPLETE.

The five sub-tabs

Overview

The verdict in context: blocking count, score and risk level, the support timeline, and patch currency.

What breaks

The findings organised by gate — the planning view. Start here when you are scheduling work.

Upgrade strategy

A phased plan for the hop, when one can be derived. The tab badge shows the phase count, or none.

Findings

The flat, filterable list of every finding with its rule id, severity and affected objects.

Add-ons

Per-add-on pre-upgrade checklists, installed version → latest catalogued.

Note

Add-on checklists are informational only. They describe work on the add-on’s own upgrade path, which you may not have chosen to take — so they carry no severity and never touch the score, risk level, or finding counts.

Support timeline

Alongside the verdict:

• Days until forced upgrade — or “timeline unavailable” when the provider or version is unknown. Not a guess.
• Standard support end and extended support end dates.
• A cost warning where extended support is billable. On EKS in particular, sliding past standard support is a line item, not just a risk.

Patch currency

A separate signal from the minor-version hop: how many patch releases behind the cluster is, with an advisory when it is behind.

Patch currency is computed after scoring and is informational only — it never affects the score, risk level, or findings. It is also not derived from your cluster: it comes from a static release calendar, which the response marks explicitly so you can tell sourced data from catalogued data.

Remediation estimate

When there are findings, the response carries an estimate: hours, days, and a cost in USD. It also carries a dataSourced flag stating whether the estimate came from observed data or from defaults — so an estimate is never presented as more authoritative than it is.

The generated-rules ledger

For every release-note item in the hop, the ledger records what happened to it. The principle: “no finding” must be a stated, evidenced result — never silence.

Each entry carries the rule id, the version it applies at, severity, the verbatim vendor sentence it came from, the evidence, and the remediation. Every rule lands in one outcome:

Outcome	Meaning
APPLIES	This cluster is affected. Affected objects are named.
CLEARED	Checked, and this cluster is not affected.
NOT_DETECTABLE	Cannot be determined remotely. Lists candidate objects to check by hand — a scope hint, never a claim of impact.
DATA_ERROR	The check could not complete.
DISABLED	The rule is turned off.

The rollup — evaluated, applies, cleared, verify-manually, data errors, disabled — always accounts for every rule. The point is that you never have to open a changelog to find out whether something was considered.

Cross-axis: security overlap

A seventh grouping appears where the two risk axes intersect: workloads that both block this upgrade and carry unresolved CVEs. Fix or replace them once, not twice. This is the “fix-first” list, and it is the reason both axes are scored against the same workload identity.

What never moves the score

Worth stating plainly, because it is a deliberate design line. The score, risk level, findings and severity counts come from the deterministic tiers alone. These are computed afterwards and are additive context only:

• add-on checklists
• patch currency
• scan coverage and freshness
• the remediation estimate
• the generated-rules ledger

Nothing informational can quietly make a cluster look safer than the tiers found it.

From the CLI

rtz risk                 # includes upgrade-axis findings
rtz risk --fail-on high  # exits 4 at or above the threshold

See CI gates for using this as a merge gate.