KernforceBook a call

Before the diagnostic

Tell us what we cannot measure ourselves.

Sixteen questions — twelve essential, four optional, and most of them a single click. They exist so the first fortnight of measurement describes your estate rather than a guess at it, and so we can tell you early if a diagnostic would not be worth running.

Nothing here is sent anywhere. The page runs entirely in your browser, stores no cookies and contacts no third party — your answers become a block of text that you copy or email yourself, and nothing reaches us until you choose to send it.

There is no score at the end. Grading your own infrastructure on a scale produces a number built from recollection, and we would only have to replace it with a measured one a fortnight later.

Not sure a diagnostic is the right thing yet? Read what it is first.

0/12 essential answered

Can we start

Five questions that decide whether a diagnostic is possible at all, and how big it is. If the answer to any of them rules us out, we would rather find that out now than three emails in.

Cloud accounts

One Organization with consolidated billing and several separate payers are different jobs. It also decides whether the cost data has a single place to read from.

Who can grant read-only access, and how long it takes

This is the critical path. Everything else waits on a read-only role in the billing account, and “we will need to ask security” is a three-week answer more often than not.

Kubernetes clusters

How many, what kind and where. Region matters because pricing does, and self-managed clusters carry costs a managed control plane hides.

Rough monthly cloud spend

A band is enough. Below roughly $5k a month an audit usually costs more attention than it returns, and we will say so rather than take the work.

Anything unusual in the next six weeks

🔴 The measurement window is fourteen days and percentiles describe whatever happens inside it. A migration, a launch or a holiday freeze in that fortnight produces numbers that describe an exception and get quoted as the rule.

What the tooling needs to know

These change how the collectors are configured and how their output has to be read. Each one has, at some point, produced a wrong number for us when it was assumed instead of asked.

How nodes are provisioned

🔴 The single biggest one. On an autoscaled fleet, an idle node and the over-requested pods on it are the same money reached from two directions — count both and the savings figure inflates. It also decides whether “resize this node” is advice anyone can act on.

Anything that already changes pod resources

🔴 A VPA or a vendor admission webhook rewrites requests after they are declared. If one is running and we do not know, our measurements describe its decisions rather than yours, and our recommendations argue with it.

Are any cluster names repeated across accounts

🔴 Ours are. Two clusters called the same thing in different accounts will silently merge in any analysis keyed on name, and workload names are not unique across clusters either. Worth thirty seconds now.

How workloads are deployed

It decides whether a recommendation can be delivered as a reviewable pull request or only as a number in a document. If manifests are Kustomize patches rather than whole objects, that changes what a change to them actually does.

Kubernetes version(s) in production

End-of-life findings depend on it, and so does whether resources can be changed in place or only by rolling the pods.

Commitments and discounts

🔴 Reserved Instances and Savings Plans change what a saving is worth — cutting usage you have already paid for saves nothing this year. Any figure computed without knowing the coverage is wrong in a direction that flatters us.

Billing data already available

Determines what we can read on day one and what has to be switched on first. A CUR export takes up to 24 hours to produce its first file, so it is worth starting before the call rather than after it.

How to read the result

Optional, and the part that decides what the report actually says. Skip any of it — but the last question is the one that most often changes what we do.

What you have already tried, and what was rejectedoptional

So we do not spend a page recommending something your team dismissed last year for a reason we could have been told.

Who reads the reportoptional

An engineer wants the query behind every figure. A CFO wants the range and the risk. We write for whoever is actually going to open it.

Obligations and audit datesoptional

We see security posture in passing while building the inventory. If an audit is coming, we can order those findings usefully instead of listing them at the end.

What would make this a waste of your timeoptional

The most useful question on this page. If the answer is “another list of things we already know”, we will either scope around it or tell you not to bother.

Your answers

This is the whole of what you would be sending. Copy it into your own email client, or use the button — either way it leaves your browser only when you send it.

Email it to us