Skip to main content
Cloud DevOps Solutions
Get a quote Talk to an engineer

Packages

Kubernetes and EKS Production Readiness Review

A Production Readiness Review examines an existing Kubernetes cluster, on EKS, AKS or GKE, against the things that cause outages and incidents: upgrades, resource limits, networking, access, security and observability. You receive a written report and a prioritised remediation plan.

Book a scoping call Request a written scope
Verified credentials Azure DevOps Engineer Expert Azure Administrator Associate Certified Kubernetes Administrator
Typical duration
Typically 1 to 2 weeks per cluster, confirmed in the written scope
Format
Fixed scope, read-only cluster access, written report and readout call
Led by
A named senior engineer

Who this is for

  • Teams about to move a workload to Kubernetes production
  • Companies that inherited a cluster nobody fully understands
  • Teams that have had a Kubernetes incident and want to prevent the next one
  • Organisations preparing a cluster for an audit or customer review

What is included

Upgrade and lifecycle posture

Version support, upgrade history and plan, add-on versions, and how risky the next upgrade is.

Resource management

Requests and limits, autoscaling, pod disruption budgets and node sizing against real usage.

Access and RBAC

Who can do what in the cluster, how humans and workloads authenticate, and standing admin access.

Network and exposure

Ingress, network policies, internal and external exposure, and cloud network configuration.

Workload security

Pod security settings, image sources, scanning, secrets handling and runtime visibility.

Observability and alerting

Metrics, logs, dashboards and whether the alerts that matter reach the right people.

Backup and recovery

Cluster state and persistent data backups, and whether a restore has ever been tested.

Cost and capacity

Idle capacity, spot and on-demand mix, and the main drivers of cluster cost.

What you receive

  • ✓A written readiness report with findings ranked by risk and effort
  • ✓A checklist scored against production-readiness criteria
  • ✓A prioritised remediation plan with suggested owners
  • ✓A readout call with your platform and application engineers
  • ✓Optionally, scoped proposals for the fixes you want help with

What we need from you

  • •Read-only access to the cloud account and cluster
  • •A platform or senior engineer as a contact
  • •Access to the infrastructure code and deployment pipelines for the cluster
  • •A list of the workloads that matter most to the business

Not included

  • –Penetration testing or formal security audits
  • –Compliance certification (we implement technical controls, we do not issue certificates)
  • –Fixing the findings (separate, scoped work)

How it runs

  1. 01

    Scoping call

    We confirm the clusters, workloads and concerns, and agree the scope in writing.

  2. 02

    Read-only access

    You provide read-only cloud and cluster roles. We do not deploy or change anything.

  3. 03

    Review and testing

    We inspect configuration and manifests, review the infrastructure code, and check behaviour against agreed criteria.

  4. 04

    Report and readout

    You receive the report and we walk through each finding and the reasoning behind its priority.

  5. 05

    Decide next steps

    You can fix findings yourselves, with us, or with another team. The findings are yours.

Every package starts with a short scoping call. We then confirm scope, deliverables and timeline in writing, and you decide whether to go ahead. Prices are quoted for that fixed scope, not as a rate card.

Who you will work with

Engagements are led by a named senior engineer, not passed to an anonymous team.

Saddique Khan

CEO, DevOps / SRE / Cloud Consultant Engineer

Meet the team

You keep everything

No lock-in, by design. If you stop working with us, nothing you rely on stops working.

Your accounts

Everything runs in cloud accounts and subscriptions you own and control.

Your code

Infrastructure code, pipelines and configuration live in your repositories.

Your documentation

Architecture notes and runbooks are written for your team and handed over.

A defined exit

We agree the handover steps in writing, and access is removed when the work ends.

Related services and technologies

Kubernetes ConsultingAWS EKS ConsultingSRE & Incident ResponseMonitoring & Observability KubernetesAmazon EKSAzure AKSGoogle GKE

Frequently asked questions

Which clusters do you support?
Amazon EKS, Azure AKS and Google GKE, plus self-managed clusters on request. The criteria are the same; the cloud-specific checks change.
Will the review affect production?
No. We use read-only access and do not run load tests or change configuration unless you ask for that and agree it in the scope.
What does ready for production mean?
We score the cluster against agreed criteria covering upgrades, resource management, access, security, observability and recovery. The scope document lists them so you can see exactly what is judged.
Can you also fix what you find?
Yes, as separate scoped work. Many teams fix the quick items themselves and ask for help with the larger ones.
How is this different from the Health Check?
The Health Check covers your whole cloud and delivery setup at a high level. The Readiness Review goes deep on Kubernetes. Teams often start with one and add the other.

Get a written scope for Kubernetes and EKS Production Readiness Review

Book a short scoping call. You receive scope, deliverables and timeline in writing, and you decide whether to go ahead.

Book a scoping call Request a written scope