The DevOps readiness checklist: 30 points you can prove.

How to use the checklist

Run it in one sitting with the engineers who own the systems and whoever owns the cloud bill. Keep a shared document open and paste the evidence next to each item as you go.

• Count only what you can prove. An item is ticked when someone can show the pipeline run, the query, the dashboard, the policy file or the post-mortem. “Mostly” and “we are about to” are both a no.
• Count per area, not overall. An area with two ticks is where to look first, and a high total can hide one weak area.
• Mark what does not apply, and say why. A team with no AI workloads can skip check 17; it should not tick it.
• Give every gap an owner and a next step. A gap with no owner is still a gap next quarter.
• There are no scoring bands here, on purpose. The checklist shows what is missing, not what level you are at. Scoring is the job of the DevOps maturity assessment, which scores six areas, maps each to a level and suggests a next step for the weakest.

Each item is a statement a sceptical reviewer could check, followed by one line on why it matters and a link to the guide that explains it. Where a check follows a published standard, the source is listed at the end of the page.

CI/CD maturity

Checks 1–6. Every other area on this list changes through the delivery pipeline, so gaps here show up everywhere else.

1. Every merge to the main branch builds, runs the automated tests and can deploy to a non-production environment with no manual step. Why it matters: CI/CD is the practice the others depend on, and a merge that waits for someone to build or test it is a queue, not a pipeline. → What is DevOps?
2. Each commit produces one immutable artifact, tagged with its commit SHA, that is promoted from staging to production and never rebuilt. Why it matters: a production rebuild means you tested one artifact and shipped another. → A reference CI/CD pipeline, stage by stage
3. Production changes arrive as reviewed commits in Git that an agent such as Argo CD or Flux pulls and reconciles, and CI holds no production credentials. Why it matters: when the pipeline pushes to production, every CI runner and third-party action is a path to production. → What is GitOps?
4. Rolling back is a single rehearsed step, a revert to the previous artifact or commit, and it has been exercised on a real service. Why it matters: a rollback nobody has run is a hope, and the middle of an incident is the worst time to learn it does not work. → GitOps implementation and rollback
5. Infrastructure is defined in version-controlled code with remote, locked state; every change is a plan reviewed on a pull request, and drift is checked on a schedule. Why it matters: console changes drift silently, and the next apply either reverts someone’s fix or fails halfway through. → Terraform state, modules and drift control
6. The five DORA metrics (deployment frequency, change lead time, change fail rate, failed deployment recovery time and deployment rework rate) are reported from pipeline data, not estimated in a meeting. Why it matters: without a measured baseline, “we ship faster now” is an assertion rather than a result. → DORA metrics explained

Kubernetes and platform readiness

Checks 7–12. If you do not run Kubernetes, read them as questions about whatever platform you deploy to: real health checks, capacity sized from usage, a supported runtime, rebuildability, and the path a new service takes to production.

7. Every workload has readiness and liveness probes that exercise its real dependencies, not a bare TCP check. Why it matters: without a readiness probe, traffic reaches pods before they are ready and every deploy shows up as connection resets. → Three Kubernetes migration mistakes
8. Every container sets resource requests from observed usage, and someone revisits them on a schedule instead of copying values from a tutorial. Why it matters: without requests the scheduler is guessing, which produces noisy-neighbour outages and nodes you pay for but do not use. → What is Kubernetes?
9. Every cluster runs a Kubernetes minor version that still receives patches, and each upgrade is rehearsed on a non-production cluster first. Why it matters: Kubernetes ships about three minor releases a year and patches each for about a year, so a cluster nobody upgrades soon falls out of support, and the eventual upgrade can turn into a rebuild. → Managed vs self-hosted Kubernetes
10. Namespaces, RBAC, network policies and Pod Security Standards are defined in code and applied to every cluster, so any cluster can be rebuilt from Git. Why it matters: a hand-configured cluster can only be rebuilt from memory, and its security settings drift one manual edit at a time. → Kubernetes consulting
11. A new service reaches production on a golden path (template, pipeline, base image, observability and deploy) without filing a ticket with another team. Why it matters: if the paved road is slower than doing it by hand, developers route around it. → What is platform engineering?
12. The internal platform has a named owner, a backlog driven by developer pain, and an adoption measure that someone reviews. Why it matters: a platform without adoption data can look healthy on its own dashboards while developers quietly bypass it. → Why developers bypass your platform

FinOps hygiene

Checks 13–18. These are the habits that keep a cloud bill explainable, built on the FinOps principle that everyone takes ownership for their technology usage.

13. One query returns last month’s spend by team and by product, and the unallocated remainder has an owner working it down. Why it matters: engineers can only own a bill they can see, and untagged spend is spend nobody manages. → What is FinOps?
14. Steady-state compute is covered by commitments (Savings Plans, Reserved Instances or committed use discounts) sized to the baseline, with coverage and utilisation reviewed monthly. Why it matters: commitments are the single biggest lever on most bills, and an unused commitment is waste paid in advance. → AWS cost optimization
15. Budget and cost anomaly alerts go to a channel that a named person reads, with monitors scoped per service or account rather than one broad monitor. Why it matters: a spike should be caught this week by an alert, not next month by the invoice, and broad monitors can average a real spike into silence. → AWS native cost tools, ranked
16. Non-production environments scale down outside working hours, and idle resources (unattached volumes, idle load balancers, forgotten snapshots) are swept on a schedule. Why it matters: nothing breaks when these are left running, so nothing prompts anyone to remove them. → What a cloud bill audit covers
17. AI and GPU spend has budgets enforced when capacity is provisioned or requests are served, not only reviewed when the invoice arrives. Why it matters: inference and training costs move in hours, so a month-end report arrives after the money is spent. → FinOps for AI: runtime cost governance
18. A recurring bill review has a named owner, and a unit cost (per customer, request or transaction) is reported next to the total. Why it matters: “the bill went up” means nothing without a denominator; the unit cost shows whether growth or waste caused it. → Cloud billing and FinOps consulting

Observability and incident response

Checks 19–24. Can you tell that users are affected, find out why, and recover, without waiting for the one person who knows the system?

19. Every user-facing service emits structured logs, metrics and traces that share a trace ID, so one request can be followed across services. Why it matters: three tools that share no context leave a human correlating by hand in the middle of an incident, when people are worst at it. → What is observability?
20. Each critical service has a dashboard showing latency, traffic, errors and saturation as users experience them. Why it matters: Google’s SRE book names these four golden signals as the ones to focus on if you can measure only four; CPU graphs alone miss what users feel. → The four golden signals of observability
21. Critical user journeys have written SLOs, and paging alerts fire on error-budget burn rate rather than on CPU or memory thresholds. Why it matters: resource thresholds wake people for things users never notice, while burn-rate alerts page when the error budget is genuinely at risk. → What is SRE?
22. Every paging alert has an owner and a runbook, and alerts nobody acts on are deleted or moved to a dashboard. Why it matters: teams learn to ignore a noisy pager, and the alert that matters gets dismissed with the rest. → The alert fatigue trap
23. Every serious incident gets a written, blameless post-mortem, and its action items are tracked until they are done. Why it matters: without tracked follow-ups, the same incident comes back and the team relearns it. → Incident response and SRE consulting
24. Each critical system has written recovery time and recovery point objectives, and a restore from backup has been rehearsed against them. Why it matters: a backup nobody has restored is an assumption, and the real recovery time is only known once someone has done it. → What multi-region actually costs

Security posture

Checks 25–30. The pipeline holds cloud credentials, runs third-party code and publishes what production runs, so most of these checks are about the delivery system itself, not only the application code.

25. CI authenticates to your cloud accounts with short-lived OIDC credentials, no long-lived cloud keys are stored as CI secrets, and the default job token is read-only. Why it matters: long-lived secrets are what most recent pipeline attacks were built to steal, and a credential valid for one job is worth far less. → DevSecOps supply chain security in 2026
26. Third-party CI actions are pinned to full commit SHAs, dependencies install from lockfiles, and changes to workflow files need review. Why it matters: version tags can be moved to a malicious commit, and GitHub calls SHA pinning the only way to use an action as an immutable release. → DevSecOps consulting
27. Secret scanning runs before merge and across Git history, and any secret it finds is rotated, not just deleted from the file. Why it matters: a deleted secret still lives in history and in every clone, and AI-assisted commits have made leaks more common. → Vibe coding’s security and tech-debt bill
28. SAST, dependency (SCA), container image and IaC scans run in CI, and a short written policy says which findings block a merge and which only warn. Why it matters: a gate that blocks on everything gets bypassed, and one that blocks on nothing is just a dashboard. → What is DevSecOps?
29. Every build produces an SBOM and a signed image, and production admission refuses images that are unsigned. Why it matters: when the next Log4Shell-class advisory lands, an SBOM turns “are we affected?” into a query, and a signature shows the image came from your pipeline. → The scan-and-sign stage of a reference pipeline
30. Every person and pipeline has its own identity through SSO with MFA, roles are least-privilege, and emergency production access is time-boxed and logged. Why it matters: shared admin logins make changes unattributable, and standing admin access turns one stolen credential into a production incident. → Access controls in audit-ready pipelines

Where the checks come from

The checks restate practices explained in the linked guides, which follow the published sources below. None of it is a proprietary framework.

• Check 3: the four OpenGitOps principles: declarative, versioned and immutable, pulled automatically, continuously reconciled.
• Check 6: DORA’s software delivery performance metrics, five metrics grouped into throughput and instability. DORA’s Quick Check sets a baseline.
• Check 9: the Kubernetes releases page (the project maintains the three most recent minor releases, each with about a year of patch support) and the release cycle page (about three releases a year).
• Checks 13–18: the FinOps Foundation’s principles, including “everyone takes ownership for their technology usage”.
• Check 20: the four golden signals in Monitoring Distributed Systems, from Google’s SRE book.
• Check 21: multiwindow, multi-burn-rate alerting in Alerting on SLOs, from Google’s SRE workbook.
• Check 23: Postmortem Culture: Learning from Failure, from Google’s SRE book.
• Checks 25–26: GitHub’s secure use reference for Actions: OIDC instead of long-lived cloud secrets, a read-only default GITHUB_TOKEN, and full-length commit SHA pins.
• Check 29: SLSA (Supply-chain Levels for Software Artifacts), the framework for build integrity and provenance.

Related: DevOps maturity assessment · DORA metrics · What is DevOps? · What a cloud bill audit covers · DevOps vs SRE vs Platform Engineering · How to choose an SRE consultancy · Engineering blog