Runtimezruntimez
runtimez / product / upgrade-readiness
product · upgrade readiness

Know what your next Kubernetes upgrade breaks — before you book the window.

Pick a target version and get every resource that breaks, ranked by blast radius. Each of the 557 upgrade rules quotes the vendor's release note word for word and ships a read-only kubectl command, so you can check every verdict yourself.

one helm install · get, list, watch only · first findings in minutes

557upgrade rules that quote the vendor
1.30 → 1.37hand-authored Kubernetes rule corpus
449config-breaker entries from kubelet and control-plane flags
9add-on catalogs, enabled on detection

What the next version breaks

The rule corpus that replaces a week of release-note reading.

Upgrade Breakage Radar

Pick a target version and get every resource that breaks, ranked by blast radius.

target versionblast radius

Rules you can audit line by line

72 hand-authored Kubernetes rules for 1.30 → 1.37, with 569 exclusions. Each rule quotes the vendor release note and ships a read-only kubectl verify command. No LLM guesswork.

72 rulesverify command

Add-ons break before Kubernetes does

480 release-note rules for Traefik, Istio, CoreDNS, Argo CD, Karpenter, cert-manager and kube-proxy. Each catalog turns on automatically when the add-on is detected.

480 rules7 add-ons

Config breakers scanners can't see

Reads kubelet /configz and control-plane flags to catch settings the target release removes. Manifest scanners like pluto and kubent can't see these.

/configzcomponent flags

CRD and operator deprecations

Counts the custom resources that will be orphaned, not just which CRD version is old.

instance count

Webhook and node-runtime skew

Admission-webhook and node-runtime checks, plus 5 version-skew rules. These are the two things that stall a control-plane roll halfway through.

9 runtime rules5 skew rules
Runtimez Upgrade Readiness tab: target version 1.39, forced-upgrade banner, and the workloads that block the upgrade and carry security risk
Runtimez Upgrade Readiness tab: target version 1.39, forced-upgrade banner, and the workloads that block the upgrade and carry security risk

Plan it, prove it, schedule it

Turn an engineering task into a budget conversation.

Forced-upgrade deadline in dollars

An end-of-support countdown, the extended-support cost of waiting, and the effort to upgrade, side by side.

EOS countdown$ exposure

Fleet breakage ranking

Which cluster to upgrade first, ranked by risk and deadline.

fleet

Gate ledger

Pass or fail per rule, with the objects named and the command to re-check it yourself.

per-rule verdict

Coverage self-assessment

Tells you what it could not see, so you can trust a green verdict.

honest coverage

Check manifests before they exist

The same rules run against a rendered bundle at PR time.

PR time

kube-upgrade-check (open source)

The same rule catalogs, byte for byte, as an offline CLI for CI. Try the CLI →

Apache-2.0CI

How it compares

vs pluto / kubent

They read manifests. Runtimez also reads CRDs, webhooks, kubelet flags, node runtimes and nine add-ons, and keeps watching after the scan.

See it on your own cluster in under an hour.

Free for your first cluster. Read-only by default. Uninstall is one helm command.