Know what state your platform is in — and whether it can still be changed.
The cluster runs, but the upgrade has been deferred for two years and nobody on the team will guarantee that what runs on it survives one. You don't know how many versions behind support you are, whether losing a single node takes production with it, or whether you could stand the cluster back up if you had to. The Kubernetes Health Check answers that: an independent read of where the platform stands, and the order in which to fix it. Fixed scope, fixed price.
Three deliverables — where the platform stands, where it should be, and how to get there.
AS-IS
Where the platform stands today
- Access to the cluster declaration and configuration, interviews with your platform, infrastructure and application owners, plus a structured questionnaire.
- An inventory with findings ranked by severity — cluster configuration and layout, security baseline against a recognised standard, resource governance, persistent storage, and how Helm charts are managed.
- How far you are from a supported version — how many versions behind, what is no longer covered, and what is missing along the way.
- Control plane health and recoverability — cluster state backed up, and a tested restore. "We don't back it up, we rebuild from the declaration" holds only when the declaration is complete.
- Whether node, pod and volume health is visible and acted on, how storage matches the workload, and the state of CNI, load balancing and ingress.
TO-BE
Where it should be
- The health and upgradability gap — what would take the service down today if a node failed, and what blocks the path to the next version.
- Distribution fit — the real options compared against your environment: licence model and where it is heading, vendor lock-in, the operating model, maturity, multi-cluster management, and the operational footprint against the team that will hold it. A recommendation for your environment, not a universal ranking.
- The target state of the platform — including what stays as it is.
ROADMAP
How to get there
- An upgrade path and its risk profile — the route to a supported version with the blockers named. The blocker is rarely Kubernetes itself: third-party images that stopped being freely available or changed licence terms, and components with nowhere to go.
- A prioritisation matrix — findings ranked by importance and effort, in a form you can put in front of management as it is.
- Findings ordered so implementation packages fall straight out of them. The health check ends with an offer, not a conclusion.
You get two reads of the same work: a written report your platform team can act on — AS-IS, TO-BE and roadmap — and an executive summary in the language your board speaks, with an executive readout to walk through both.
Fixed scope, fixed price
One health check, two levels
The deliverables are the same either way. What changes is how much environment there is to assess — more clusters, more sites, more regulation simply take more work — and the price follows that.
Standard
excl. VAT · paid 50% at kick-off, 50% on delivery
Simpler environments
One or two clusters, a single site or a single cloud, one distribution, no service mesh, one platform or infrastructure team, and light or no regulation.
Full scope included — AS-IS, TO-BE and roadmap, with the upgrade path and its blockers.
OrderEnterprise
excl. VAT · paid 50% at kick-off, 50% on delivery
Complex environments
Three or more clusters, a multi-site or hybrid estate, several distributions or an on-prem enterprise platform, multi-tenancy with isolation in scope, and regulated settings — bank, insurer or payment institution with an auditor or a regulator in scope.
Full scope included — same deliverables, greater depth as the environment demands.
OrderWhich one is yours
It's Enterprise if any one of these is true:
- three or more clusters, or a multi-site or hybrid estate;
- a regulated environment with an auditor or a regulator in scope;
- distribution fit is a real decision, not a check question.
Three more will push a borderline environment up: three or more versions behind support, a service mesh already running, or multi-tenancy with isolation in scope. Everything else is Standard.
We confirm the tier with you in a 30-minute scoping call before you order — you never find out mid-delivery that you bought the wrong one. And if the environment sits above Enterprise — multi-site, regulated and several distributions at once — you get a quote instead of a tier.
Delivered in production
Health checks behind real decisions
Independent platform assessments and upgrade planning for regulated fintechs, banks and critical infrastructure operators — each one the first step, not the whole engagement.
A platform running in production at a regulated fintech, with an upgrade prepared without downtime — third-party image dependencies resolved as a separate change before it, not during.
Read the case study →
🇨🇿
A discovery assessment across three areas of a banking group — findings ranked by importance and effort, and the implementation packages that came out of them.
Read the case study →
Platform selection advisory for a critical infrastructure operator — a distribution comparison, a concept design and a working demo. Distribution fit as a full deliverable.
A health check and upgrade planning that turned into a long-term platform operations partnership — the follow-on path this product is built for.
Read the case study →We also run a Kubernetes platform of our own — the same practice, on our own cluster: an RKE2 environment with the platform layer declared in Git and reconciled by ArgoCD. If you want to see how we work before you buy the report, take a look at the live demo.
How far are you from a supported version — and what happens if you drain a node?
A fixed-scope, independent read of the platform: findings by severity, distribution fit, an upgrade path with its blockers named, and a prioritised roadmap. Two clear prices. Most scoping calls take 30 minutes — no pitch, no deck.