Kubernetes Production Readiness Checklist
This checklist makes twenty-four statements about a cluster that already serves production, grouped into the eight areas we use to define “production-ready”. You tick what is true today. Next to every statement that stays open is the first step you can take without a budget and without us.
Direct download, no form, no email address. And what you tick on this page stays in the browser: we learn that the list was used, not what it says about you.
Who it is for
For the people who run the cluster and for the people who answer for it: platform and operations teams, engineering leads, and whoever has to decide whether the next application is allowed anywhere near it. Work through it with two or three people — someone from operations, someone from development, and whoever gets woken up at night.
How to use it
Only tick what is already true — not what is in a ticket, planned, or sitting in a repository nobody has touched for months. Answer for production, not for the best environment you own. If the room disagrees about a statement it counts as open: two people answering it differently is itself a finding.
What depends on your version
Reviewed:
Some of these depend on the Kubernetes version you run: APIs disappear with minor releases, and what still works in one version is gone in the next. So the notes on this page say when something changed — not which versions still get patches today. The project's own release page answers that, and it answers it more currently than a page of ours ever could. The date on each note is when we last reviewed the criteria.
How these criteria were reviewed
The items come from running clusters in production and were read back against the project's published documentation; the sources are below. They were reviewed by the person who also does the work — no external body was involved, and this is our standard rather than an industry one. If you think an item is wrong, tell us: a reasoned correction changes the list.
The checklist
Upgrades are planned work
If this one is openPut the cluster version and its end of support in the same document as your other deadlines. On a managed offering its own schedule applies as well — and that one is usually the earlier of the two.
Version noteReviewed: The project ships a minor release roughly every four months and patches each one for about fourteen months. Managed providers set their own, often shorter, deadlines on top of that.
If this one is openRun pluto or kubent once against what you have today. What comes out is the work list for your next upgrade, and it does not get shorter by waiting.
Version noteReviewed: APIs go away with minor releases: PodSecurityPolicy, policy/v1beta1 PodDisruptionBudget and batch/v1beta1 CronJob were removed in 1.25. What your target version drops is in its own migration notes.
If this one is openWrite down your add-ons — CNI, ingress controller, cert-manager, CSI drivers, monitoring — and the cluster versions each supports. The narrowest range decides your upgrade path, not the cluster.
The desired state lives in Git
If this one is openCompare what runs in the cluster with what the repository says once. Whatever differs is either drift or an intention nobody wrote down — both belong on the same list.
If this one is openTurn on the drift view in your delivery tooling and decide who reads it. A view that belongs to nobody is not a view.
If this one is openSearch the repository for secret manifests with values embedded in them. If you find some, the first move is not rotation but deciding where secrets come from in future.
Recovery has been rehearsed
If this one is openSchedule draining a node in a quiet hour and watch. If a service drops out, it is missing replicas, a PodDisruptionBudget, or spreading across failure domains.
If this one is openTake the most recent backup and restore a single namespace into a test environment. How long that takes is your actual recovery time; everything else is an estimate.
If this one is openGo through your StatefulSets and PersistentVolumeClaims and note beside each who backs the data up and where to. Anything left blank is unprotected, however often the cluster itself is backed up.
Access is answerable
If this one is openCount the kubeconfig files with administrative rights in circulation. Each one is an entrance with no name on it, and it survives the person leaving.
If this one is openList the bindings to the cluster administrator role and write down why each exists. Whatever cannot be justified is the first candidate for removal.
If this one is openPut Pod Security Admission on one namespace in warning mode first and read what it flags. Enforce once that list is short.
Version noteReviewed: PodSecurityPolicy was removed in 1.25 and Pod Security Admission is the built-in successor. Clusters that only switched the old policy off at the time usually have no policy here at all today.
Observability answers questions
If this one is openTake your most important service and answer, from the views you already have, whether it is working for users right now. If that takes several dashboards, exactly one view is missing.
If this one is openFind the last incident in your logs without connecting to a node. Where that fails, either the collection or the retention is missing — and both are discovered too late by definition.
If this one is openCompare requested resources against real usage for two or three workloads. The gap explains your cloud bill and your scheduling at the same time.
Every alert has a recipient
If this one is openGo through the alerting rules and delete the ones nobody acted on last quarter. That is not a loss of safety, it is the end of a habit.
If this one is openCount the alerts from the last on-call week and mark which ones led to an action. The ratio tells you whether your rotation is working or just awake.
If this one is openAsk the next person on call what they do first when the ingress controller fails. If the answer is a name rather than a step, the runbook is missing.
Workloads arrive through a documented path
If this one is openWrite down what actually happened during the last onboarding and turn it into a template. The second run shows you what the first version left out.
If this one is openFind the deployments with no resource requests. Without them the scheduler plans blind, and the first traffic spike distributes the consequences across your nodes at random.
If this one is openLook at the containers with the most restarts. A liveness probe that fires on an overloaded dependency amplifies an incident instead of resolving it.
At least two people can do it
If this one is openTake the step you find hardest to answer for and have the second person carry it out in the next fortnight, with the first one sitting beside them.
If this one is openLet the next small incident be handled by someone who does not know the runbook, with the experienced person watching. The questions they ask are your gaps.
If this one is openCreate one page holding those four facts and carry it forward at the next upgrade. If it is still accurate at the one after that, you have a procedure rather than a note.
What is open for you
— / 24 items open
Every box is ticked. This list finds nothing more with you — which is not the same as production-ready. What is missing here are the questions you can only ask with the cluster in front of you.
The result is worked out in your browser. We learn that somebody went through the list, never which items were open — and what you get is a work list, not a certificate.
Reading the result
Count the open items, not the ticked ones. Where they sit matters more than how many there are: three open items in recovery weigh more than three spread across eight areas, because together they describe an outage you do not come back out of.
0 to 3 open
Isolated gaps, usually in one place. That is maintenance: take the open items one at a time, in the order of the areas. And read the paragraph below — an empty list is not the same as production-ready.
4 to 10 open
A visible pattern. Check first whether the open items cluster in one or two areas. If they do, there is usually a shared cause, and fixing that is cheaper than ten separate fixes.
11 or more open
The cluster runs, but it is not carrying anything yet. Here the order matters more than the volume: first the way back — recovery, rollback, access — then the way forward. Automating first means automating a state you cannot restore.
What it does not do
This list is not an audit, not a certificate and not a sign-off. It cannot see your cluster, does not know your traffic and has no idea what an outage costs you — it only knows what you click. Every box ticked means these questions find nothing more. It does not mean your cluster is production-ready, because the questions missing here are precisely the ones nobody can ask without looking at the environment.
What comes next
The eight areas are the ones our Kubernetes consulting uses to define “production-ready”. In an assessment we then look at the cluster instead of at your impression: manifests, roles, alerts, backups, and the actual path a deployment takes into production. The result is a sorted list with effort and impact against each item. If your open items all sit in one area we will say so — then you do not need an assessment, you need work in the right place.
Left open where it hurts?
Send us the areas where most of the boxes stayed empty, plus two sentences about your cluster. You get an assessment of what to do first — and of whether you need us for it at all.
Not sure yet whether this is the right engagement? Settle it in a quarter of an hour, with the engineer who does the work. Book a fit check