Key takeaway
- A DevOps checklist of 12 auditable checks across teams, pipelines and feedback, with DORA metrics, AI impact and an adoption order for leaders.
A DevOps checklist is a short list of practices your teams can audit with evidence, not a statement of culture. The twelve checks below cover how teams are organised, how code reaches production, and how you learn from what happens there. Each has an owner, a test you can run and a sign that it is working.
This post covers delivery and operating practice. For security gates in the pipeline, use our DevSecOps checklist, and for code-level controls use the application security checklist. For measuring the result, see DevOps metrics.
What is a DevOps checklist and who should own it?
A DevOps checklist turns broad principles into yes-or-no questions. Each question needs one named owner, a place where evidence lives (a repository setting, a pipeline report, a dashboard) and a review date. A checklist with no owners becomes a poster. A checklist with owners becomes an audit of how software actually moves from commit to production.
Engineering leaders usually own the delivery checks, platform leads own the pipeline and environment checks, and product leaders own the customer and goal checks. The CIO or CTO sponsors the whole list and reviews the results.
Which twelve checks belong on a DevOps checklist?
The table groups the checks into three areas. Treat the middle column as a test you can pass or fail, not as advice.
| Check | What passing looks like | Evidence to collect |
|---|---|---|
| Team and culture | ||
| 1. Experiment and learn | Teams run small, time-boxed experiments and record what they learned. | Experiment log with outcomes |
| 2. Cross-functional teams | A team holds development, operations, test and product skills, and can ship without a hand-off queue. | Team charter; count of external approvals per release |
| 3. Customer focus | Releases link to a customer problem and a measure of whether it was solved. | Release notes tied to goals |
| 4. Business alignment | Every team can state the business objective its work supports. | Quarterly objectives mapped to backlogs |
| Delivery pipeline | ||
| 5. Know your life cycle | You can show how long a change takes from commit to production and where it waits. | Value-stream map or lead-time report |
| 6. Source control for everything | Application code, infrastructure definitions and pipeline configuration are all versioned and reviewed. | Repository list; branch protection settings |
| 7. Automate builds and deployments | No manual steps between merge and a deployable artefact. | Pipeline definition in version control |
| 8. Continuous integration | Changes merge to a shared branch often, and every merge triggers a build and automated tests. | CI run history; failing-build response time |
| 9. Continuous delivery | Any passing build can be released on demand, with a tested rollback. | Release runbook; rollback drill record |
| Operate and improve | ||
| 10. Continuous feedback | Production signals (errors, latency, user reports) reach the team that wrote the code. | Alert routing; incident review notes |
| 11. Containers and environments | Environments are reproducible from code, so a build behaves the same in test and production. | Environment definitions; drift report |
| 12. Document the system | Runbooks, recovery steps and architecture decisions are current and findable. | Docs review date; last restore test |
For the pipeline checks, see CI/CD pipeline stages and practices, continuous delivery on Google Cloud, continuous testing and the role of containers in DevOps.
How do you know the checklist is working?
Passing a checklist is not the goal. The goal is faster, safer delivery. DORA, the DevOps Research and Assessment programme, defines five software delivery metrics on dora.dev. It groups them into throughput and instability.
| Group | Metric | DORA definition (summarised) | Checklist items it tests |
|---|---|---|---|
| Throughput | Change lead time | Time for a change to go from committed to version control to deployed in production | 5, 7, 8 |
| Throughput | Deployment frequency | Number of deployments over a period, or time between deployments | 7, 9 |
| Throughput | Failed deployment recovery time | Time to recover from a deployment that fails and needs immediate intervention | 9, 10, 12 |
| Instability | Change fail rate | Ratio of deployments that need immediate intervention after release | 8, 11 |
| Instability | Deployment rework rate | Ratio of unplanned deployments that result from a production incident | 10, 12 |
Use the metrics to see which checks to fix first, and avoid turning them into individual targets. Our DevOps metrics guide covers how to collect them and what to add.
How does AI-assisted development change the checklist?
The 2025 DORA report on AI-assisted software development finds that AI acts mainly as an amplifier, magnifying an organisation's existing strengths and weaknesses, according to the DORA 2025 report page. It says the largest returns come from the surrounding organisational system, not from the tools alone.
For a checklist owner, that means checks 5 to 10 matter more as code arrives faster: small changes, automated tests and fast feedback decide whether extra code becomes extra value or extra incidents. Add two questions. Can you tell which changes were AI-assisted when you review an incident? Does a human review every change that reaches production? For wider trends, read DevOps trends for 2026.
Where AI agents themselves take delivery actions, such as opening pull requests or triggering deployments, they need the same ownership and audit trail as a person. ElixirClaw is, according to its site, an agentic OS platform to build, orchestrate and govern AI agents and automation workflows while keeping humans in control. AgentGRC keeps autonomous agent actions inside policy, with the audit trail risk teams need.
How is this different from the DevSecOps and application security checklists?
| Checklist | Question it answers | Use it when |
|---|---|---|
| DevOps checklist (this post) | Do teams, pipelines and feedback loops let us ship small changes reliably? | You are setting up or auditing delivery practice |
| DevSecOps checklist | Which security checks run at each pipeline stage, and who owns them? | You are adding gates and pipeline hardening |
| Application security checklist | Is the application itself resistant to common flaws? | You are reviewing code and design controls |
On secure development more broadly, NIST publishes the Secure Software Development Framework as SP 800-218, version 1.1, February 2022, on its publication page. The framework gives organisations a core set of high-level practices to add to any software life cycle.
In what order should you adopt the checklist?
- Weeks 1 to 2: baseline the five DORA metrics and map lead time for one product. Do not fix anything yet.
- Weeks 3 to 6: pass checks 6 to 8 (source control, automation, continuous integration) for that product.
- Weeks 7 to 10: pass checks 9 and 11 (release on demand, reproducible environments) and run a rollback drill.
- Weeks 11 to 14: connect production signals to the owning team (check 10) and write the first runbooks (check 12).
- Then: extend to the team and culture checks across more products, and review the list every quarter.
The week ranges are a suggested pace for one product, not a benchmark. Adjust them to team size and release risk.
What are the trade-offs, and when is a checklist not enough?
- Checklists can become compliance theatre. If teams tick boxes without evidence, the list hides problems. Ask for the artefact each time.
- Metrics can be gamed. A team told to raise deployment frequency can split work into meaningless releases. Review the five metrics together.
- Culture is not a checkbox. Checks 1 to 4 only show intent. Look at how incidents are discussed and who gets heard.
- Small teams may not need all twelve. A two-person team can combine checks 6 to 9 into one pipeline review.
If many releases still fail despite passing the list, look at architecture, test quality and team load, which a checklist does not measure.
To map one delivery decision your agents should make, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.
What should you plan for in 2027?
The European Commission page on the Cyber Resilience Act sets dates that reach any team shipping software into the EU.
- 11 September 2026: manufacturers must report actively exploited vulnerabilities, so check that production signals (check 10) reach an owner who can act on them.
- 11 December 2027: the main obligations apply, including handling vulnerabilities over the lifecycle of a product. Make sure your runbooks and rollback drills (checks 9 and 12) are current before then.
Check with counsel which of your products are in scope.
Frequently asked questions
What should a DevOps checklist include?
At minimum: cross-functional teams, source control for code and infrastructure, automated builds, continuous integration, continuous delivery with tested rollback, production feedback to developers, reproducible environments and current documentation. Each item should have an owner and evidence.
Which metrics show that DevOps practices are working?
DORA defines five: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. The first three describe throughput and the last two describe instability.
How is a DevOps checklist different from a DevSecOps checklist?
A DevOps checklist covers how teams and pipelines deliver software reliably. A DevSecOps checklist covers the security checks that run at each pipeline stage and how the pipeline itself is protected.
Does AI-assisted coding change the checklist?
The 2025 DORA report describes AI as an amplifier of existing strengths and weaknesses. Small changes, automated tests, fast feedback and human review of production changes matter more when code is produced faster.
How often should we review the checklist?
There is no standard interval. A quarterly review is a practical starting point, with an extra review after any major incident or change in tooling.
Explore the XenonStack platform family: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AgentGRC · AgentSRE · AgentAnalyst · AgentInstruct · AgentRAI · AgentScrum · AgentSearch · AgentForce · AI Aviator · SAIF Aviator · CohortIQ · XenonStack AI · XenonStack UAE
