DevOps maturity assessment: score your setup in 10 minutes

What a DevOps maturity assessment measures

Strip out the consulting vocabulary and a DevOps maturity assessment asks four questions:

1. How does a change get to production, and how much of that path is automated and reviewed?
2. Can you rebuild production from code, or is it a snowflake somebody built in a console?
3. How do you find out something is wrong, and how fast can you fix it?
4. Who can do all of the above, and what happens when they're on holiday?

Everything else (security hygiene, cost control, documentation) hangs off those four. A good assessment produces a level, a list of specific gaps, and an order to fix them in. A bad one produces a radar chart and a quote.

It's also worth saying what it doesn't measure. It won't tell you whether your architecture is right, whether your tests are any good, or whether the team is happy. It's about the delivery and operations machinery, which is the part that quietly decides how fast everything else can move.

DORA metrics and DevOps KPIs: the numbers behind the levels

The DORA metrics come from years of the State of DevOps research and they're the closest thing the industry has to agreed DevOps KPIs. Four of them, plus a fifth that got added later:

• Deployment frequency: how often you ship to production. Daily or on demand at the top; monthly or "when the release is ready" at the bottom.
• Lead time for changes: time from a commit being merged to it running in production. Hours at the top; weeks at the bottom.
• Change failure rate: the share of deployments that cause a problem needing a fix, rollback or patch.
• Time to restore service: how long an incident takes to resolve once it's noticed.
• Reliability (added later): whether you meet whatever availability and performance targets you've set.

You don't need a tool to start. If you deploy through GitHub Actions, your deployment frequency and a rough change failure rate are a query away:

# Production deploys in the last 100 runs of the deploy workflow, and how many failed
gh run list --workflow deploy.yml --branch main --limit 100 \
  --json conclusion,createdAt \
  --jq '[.[] | select(.conclusion=="success")] | length as $ok
        | "ok: \($ok)  failed: \(100 - $ok)  first: \(.[-1].createdAt)  last: \(.[0].createdAt)"'

Track them monthly, roughly, by hand if necessary. The point isn't precision; it's noticing that lead time doubled after the new approval step was added, or that half of all incidents follow a Friday deploy.

The DevOps maturity model: five levels

There are dozens of DevOps maturity models (Gartner has one, so does every consultancy). They all describe the same climb. Here's the version we use, with the DevOps maturity levels described by what you'd actually see on a Tuesday afternoon.

Level 5 is where platform engineering lives: a team whose product is the internal platform the other engineers build on. It's the right answer at a certain size and an expensive distraction before it. Most of the value is captured at level 4.

Run the DevOps assessment questionnaire

Twenty-five statements, five areas, about ten minutes. It's the same DevOps assessment questionnaire we use on a first call, minus the follow-up questions. Answer for your main production system, not your best one.

DevOps best practices: what good looks like in each area

The questionnaire tells you where you are. This is what "Yes" looks like in each area, with the DevOps best practices that actually move the score, and a couple of snippets because a description is never as clear as the config.

# The shape of a GitHub Actions deploy job: build once, deploy the digest
jobs:
  build:
    runs-on: ubuntu-latest
    outputs: { digest: ${{ steps.push.outputs.digest }} }
    steps:
      - uses: actions/checkout@v4
      - id: push
        uses: docker/build-push-action@v6
        with: { push: true, tags: ghcr.io/acme/api:${{ github.sha }} }
  deploy:
    needs: build
    environment: production
    steps:
      - run: ./deploy.sh ghcr.io/acme/api@${{ needs.build.outputs.digest }}

terraform {
  backend "s3" {
    bucket         = "acme-tfstate"
    key            = "prod/network.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "acme-tfstate-lock"
    encrypt        = true
  }
}

A DevOps roadmap from level 2 to level 4

The most common question after an assessment is "fine, but what first?" Here's the DevOps roadmap we'd follow for a typical SaaS team at level 2. It is deliberately boring. The order matters more than the speed.

First: make production rebuildable. Production infrastructure in Terraform with locked remote state. CI/CD for the service you deploy most. MFA everywhere, no shared accounts, secrets in a secrets manager. Automated backups with one restore tested and timed. Owner and environment tags on everything. This column is also most of what a SOC 2 auditor tests first, which is why we tell teams heading for an audit to start here.

Next: make problems visible. Four signals per service on a dashboard. Alerts on symptoms with a named responder. Centralised logs with retention set. Staging rebuilt from the same code as production. Runbooks for the five things that happen most.

Then: measure and tighten. DORA metrics tracked monthly. Post-incident reviews that produce actions somebody does. Dependency and image scanning in the pipeline. Access reviews and a cost review on the calendar. A second person able to deploy and operate every critical service.

Three columns, no dates, because the time each takes depends on how much of your infrastructure was clicked together and how many services you run. A team with one monolith and a database can get through the first column quickly. A team with twenty microservices and three clouds can't, and shouldn't pretend otherwise.

The short DevOps checklist

If you only fix ten things, this is the DevOps checklist we'd hand you after the assessment:

1. Every production deploy goes through a pipeline, never a laptop.
2. All production infrastructure is in code with a plan reviewed on every change.
3. MFA on cloud, source control and anything with production access.
4. Secrets in a secrets manager; none in repos or CI variables.
5. One restore tested and written down, with the time it took.
6. Alerts on error rate and latency that page a named person.
7. Log retention set on every log group.
8. Runbooks for the top five operational tasks.
9. Owner and environment tags on everything; the bill reviewed monthly.
10. At least two people who can deploy and recover each critical service.

DevOps audit vs health check vs maturity assessment

Three names that get used interchangeably and shouldn't be. A DevOps audit is the compliance-flavoured one: checking that your delivery process matches a policy or standard, often with an auditor in the room, and it produces findings. A DevOps health check is a quick, usually free look at a pipeline or a cloud account to spot obvious problems; vendors use it as a door-opener and it's fine as long as you know that. A DevOps maturity assessment is the broad one: where you are across delivery, infrastructure, operations, security and cost, and what to do next. If someone sells you an "Azure DevOps health check", be aware they probably mean the Microsoft product (Azure DevOps Services, pipelines and boards), not your DevOps practice in general.

DevOps for SaaS: the traps that generic models miss

DevOps for SaaS has a few problems that a generic maturity model glosses over:

• Multi-tenancy makes every incident a customer incident. A noisy neighbour, a migration that locks a shared table, a cache that's shared across tenants. Your monitoring needs a per-tenant view, and your runbooks need a "which customers are affected" step.
• Deploy windows get negotiated away. Enterprise customers ask for change freezes and notice periods. The answer is small, frequent, boring deploys with a tested rollback, not a monthly release train that makes every deploy scary.
• Security questionnaires arrive before you're ready. The first big customer will ask about backups, access control and SOC 2. Everything in the first roadmap column is your answer; do it before the questionnaire, not during.
• Costs scale with customers, not usage. Per-tenant resources (databases, buckets, queues) multiply quietly. Tagging by tenant or product from the start is the only way to see it. The cloud cost optimisation guide covers what to do when it's already got away from you.

Where managed DevOps services fit

Some teams run the assessment, read the roadmap, and do it themselves. Good. Others look at the first column and realise nobody has time for it between feature work and the on-call rota. That's the gap managed DevOps services exist for: an outside team that builds the pipeline, infrastructure and monitoring, then operates them under agreed hours and responsibilities, so the level goes up and stays up. We wrote a separate guide on what DevOps managed services include and how to choose a provider.

One distinction worth knowing, because the search results blur it: "AWS managed services" usually refers to either AWS Managed Services (AMS), Amazon's own enterprise operations offering, or to AWS's managed products like RDS and EKS. Neither is the same as a managed DevOps provider working in your account. RDS manages the database engine; nobody at AWS is going to notice your backups were never restore-tested or that the deploy pipeline depends on Dave.

If you want an outside view, our fixed-price DevOps assessment is this exact framework run on your real pipelines, accounts and alerts with read-only access: one week, a written score per area, a DORA baseline, the AWS waste priced per month and a 90-day plan. If you then want help with the work, the managed DevOps plans pick up from that plan, and the pricing page lists what each one costs. SaaS teams that also need cost control and SOC 2 readiness tend to take the Secure SaaS Growth Bundle.