Free Tool · 18 Questions · Nothing Stored

DevOps maturity assessment:
find the area holding you back.

Eighteen questions across delivery, infrastructure, reliability, observability, cost and security. Each area scores from Reactive to Optimizing, and your two weakest areas come with a concrete next step. Runs entirely in your browser.

Start the assessment → How the score works

A DevOps maturity assessment is a structured self-check that scores how a team ships, runs, secures and pays for software against a fixed scale of practice levels. This one asks 18 questions across six areas and returns a level from Reactive to Optimizing for each, plus the two weakest areas to fix first.

DevOps maturity self-assessment

Eighteen questions, three for each of six areas. Answers are numbered from 0 (least mature) to 3 (most mature). With JavaScript on, this becomes a scored form; without it, add up the three answers in each area and read your level from how the score works.

Delivery (questions 1–3)

  1. How often does your team deploy to production?
    1. Less than once a month
    2. Between once a week and once a month
    3. Between once a day and once a week
    4. At least daily, up to on demand (several deploys a day)
  2. How long does a committed change take to reach production?
    1. More than one month
    2. One week to one month
    3. One day to one week
    4. Less than one day
  3. When a deployment fails and needs immediate intervention, how long does recovery take?
    1. More than one week
    2. One day to one week
    3. Less than one day, but more than an hour
    4. Less than one hour

Infrastructure (questions 4–6)

  1. How much of your cloud infrastructure is defined as code?
    1. Little or none; most changes are made by hand in a console
    2. Some; core pieces are in code, the rest is manual
    3. Most of production is in code, with occasional manual changes
    4. All of it, changed only through reviewed code and a pipeline
  2. Could you rebuild a production-like environment from scratch?
    1. No; environments are hand-built and differ in undocumented ways
    2. Partly, with runbooks and days of manual work
    3. Yes, from code, with some manual steps and tribal knowledge
    4. Yes, automatically; new environments are created from code routinely
  3. How do you find drift between your code and what is actually running?
    1. We don't; drift is found when something breaks
    2. Occasionally, by running a plan or diff by hand
    3. Scheduled drift checks alert a named owner
    4. Continuous reconciliation (GitOps) detects and corrects drift

Reliability (questions 7–9)

  1. Do your key services have SLOs with error budgets?
    1. No defined reliability targets
    2. An SLA or informal targets, but nothing measured against them
    3. SLOs on key services, measured and reviewed
    4. SLOs with an agreed error-budget policy that changes priorities
  2. What happens after a customer-facing incident?
    1. We fix it and move on; no written review
    2. Postmortems for major outages; action items often stay open
    3. Blameless postmortems for significant incidents, action items tracked
    4. Blameless postmortems are routine, actions are closed and trends reviewed
  3. How heavy are on-call load and manual operational work (toil)?
    1. Constant firefighting; planned work rarely happens
    2. Frequent pages and manual toil crowd out planned work
    3. Manageable; toil is known and shrinking
    4. Measured and capped; pages are rare and actionable

Observability (questions 10–12)

  1. How well are your logs, metrics and traces connected?
    1. Logs only, or scattered tools nobody correlates
    2. Logs and metrics in separate tools, correlated by hand
    3. Logs, metrics and traces, partly linked by shared IDs
    4. All three correlated through shared context such as a trace ID
  2. What do your pages and alerts fire on?
    1. Few or no alerts; users tell us first
    2. Static thresholds on causes such as CPU or memory
    3. User-facing symptoms such as error rate and latency
    4. SLO burn rate, with multiwindow alert rules
  3. How long does it usually take to find the root cause of a production issue?
    1. Days, or never conclusively
    2. Hours, with several people and some guesswork
    3. Under an hour for most issues
    4. Minutes; the telemetry points at the cause

Cost (questions 13–15)

  1. Roughly what share of cloud spend can you allocate to a known owner (team or product)?
    1. Less than 70%; much of the bill has no owner
    2. 70% to 85%
    3. 85% to 90%
    4. More than 90%, with tagging enforced on new resources
  2. How often do you review commitments (reservations, savings plans) and rightsize resources?
    1. Never, or only when the bill spikes
    2. Once a year, or ad hoc
    3. Quarterly, with a named owner
    4. Monthly or continuously, largely automated
  3. What happens when cloud spend jumps unexpectedly?
    1. We find out when the invoice arrives
    2. Someone notices in a monthly review
    3. Automated anomaly alerts fire, but nobody clearly owns them
    4. Anomaly alerts go to the owning team, who act on them quickly

Security (questions 16–18)

  1. Where do your application and infrastructure secrets live?
    1. In code, config files or shared documents
    2. In CI variables or env files, rarely rotated
    3. In a secrets manager, with some rotation
    4. In a secrets manager with automated rotation, and short-lived credentials where possible
  2. How does CI authenticate to your cloud, and how are third-party actions referenced?
    1. Long-lived admin keys stored in CI; actions referenced by floating tags
    2. Scoped long-lived keys; some actions pinned
    3. OIDC for most pipelines; most actions pinned to commit SHAs
    4. OIDC everywhere with least-privilege roles; every action pinned to a full-length commit SHA
  3. Can you prove what is running in production and how it was built?
    1. No; we could not list what is inside a running image
    2. SBOMs for some builds
    3. SBOMs for every build, and images are signed
    4. Signed provenance, verified at deploy time by policy as code
Answer the questions to see your maturity level.0 of 18

Runs in your browser. The tool sends and stores nothing: your answers only appear in this page’s address so you can bookmark the result. Like any address, it appears in our web server’s access logs if you reload the page or follow a link from it to another page on this site.

Review your result with an engineer →

The four maturity levels

Every area lands on one of four levels. The names describe how work happens, not how good the team is: a Reactive area is usually one nobody has had time to invest in yet.

DevOps maturity levels and the area scores that map to them
LevelArea scoreWhat it looks like
Reactive0–2Work depends on a few people and on memory. Changes are manual and infrequent, users find problems first, and nobody can say with confidence what is running or what it costs.
Repeatable3–5The basics exist and are written down, but they are applied unevenly. Pipelines, runbooks and tags cover the important systems; results still depend on who is on shift.
Measured6–7Practices are standard and measured. Targets such as SLOs, delivery metrics and cost allocation are reviewed on a schedule and change what the team does next.
Optimizing8–9Measurement drives continuous improvement. Guardrails are automated, teams serve themselves, and the numbers decide the next investment rather than report on the last one.

What to do next in each area

Each area has one next step per level. The result panel shows the step for your two weakest areas; the full set is here so you can plan beyond them.

Delivery

Reactive → Repeatable. Put every service on one automated build, test and deploy pipeline, and ship small changes on a regular cadence instead of large, infrequent releases. Start recording deployment frequency and lead time now so there is a baseline to improve against; the DORA metrics guide shows how.

Repeatable → Measured. Shrink batch size: short-lived branches, automated tests that gate every merge, and a rollback that is one command. Track the five DORA metrics per service and review them with the team every month. What is DevOps? covers the practices behind the numbers.

Measured → Optimizing. Make releases boring: progressive delivery (canary or blue-green) with automatic rollback when an SLO is breached, and Git as the record of what is deployed where. GitOps is the usual way to get there.

Holding Optimizing. Watch the instability side as volume grows: change fail rate and deployment rework rate, not only speed. Keep pipeline run time under review, because a slow pipeline quietly pushes teams back to batching. An outside DevOps review can catch the slide early.

Infrastructure

Reactive → Repeatable. Start with what would hurt most to lose: networking, identity and access, and the production cluster. Bring them under Terraform or OpenTofu with remote, locked state, and make a reviewed pull request the only way they change. See Terraform consulting.

Repeatable → Measured. Turn repeated patterns into modules, run a plan on every pull request, and rebuild a non-production environment from code on a schedule to prove it still works. If the tool choice is still open, compare Terraform, OpenTofu and Pulumi.

Measured → Optimizing. Add continuous drift detection and move cluster and application configuration to a pull-based controller, so the cluster reconciles itself to Git and manual changes are reverted. See what GitOps is and GitOps consulting.

Holding Optimizing. Treat the infrastructure code as a product: golden paths and self-service templates, so teams create compliant environments without filing a ticket. That is platform engineering; judge it by adoption rather than by features shipped.

Reliability

Reactive → Repeatable. Pick the two user journeys that matter most, define an indicator for each, and set an SLO you already meet. Write a short, blameless postmortem after every customer-facing incident. What is SRE? explains SLOs and error budgets.

Repeatable → Measured. Agree an error-budget policy with product, development and on-call engineers, so a spent budget changes priorities instead of starting a debate. Track postmortem action items to closure. The uptime and SLA calculator turns a target into allowed downtime.

Measured → Optimizing. Measure on-call load and toil, then cap them: the Google SRE workbook targets at most two incidents per on-call shift and limits SRE operational work to 50% of time. Automate the biggest toil item every quarter. See SRE consulting.

Holding Optimizing. Go looking for failures you have not had yet: game days and controlled failure tests on the journeys your SLOs cover, and incident trends reviewed across teams rather than one postmortem at a time. SRE for SaaS goes further.

Observability

Reactive → Repeatable. Before buying anything, structure your logs with a request ID and collect latency, traffic, errors and saturation for every user-facing service. Start with the four golden signals.

Repeatable → Measured. Add distributed tracing on the critical paths and carry one trace ID through logs, metrics and traces, so an engineer can pivot between them in one step. Standardise instrumentation on OpenTelemetry. See what observability is.

Measured → Optimizing. Page on symptoms, not causes: alert on SLO burn rate with multiwindow rules, and send cause-based alerts such as CPU to a ticket queue instead of the pager. The alert fatigue trap explains why.

Holding Optimizing. Give telemetry a budget and an owner: retention tiers, deliberate trace sampling, and instrumentation in the definition of done. Review the observability bill monthly, like any other cloud cost. See observability consulting.

Cost

Reactive → Repeatable. Get one view of the bill and a tagging standard (team, product, environment) enforced on new resources, then clear the obvious waste: idle, oversized and forgotten resources. The cloud waste calculator gives a first estimate.

Repeatable → Measured. Push allocation towards the FinOps Foundation’s Walk goal of 85% of cost with a known owner, give every shared cost a split rule, and review commitments and rightsizing on a fixed cadence with a named owner. The reserved instance calculator helps size commitments.

Measured → Optimizing. Route anomaly alerts to the team that owns the spend, report unit cost (per customer or per request) next to the total, and forecast against budget. What is FinOps? covers the operating model.

Holding Optimizing. Automate the routine: schedules for non-production, rightsizing applied through code, and cost checks in pull requests. A periodic cloud bill audit catches what automation misses.

Security

Reactive → Repeatable. Get secrets out of code, config files and chat: move them into a secrets manager, rotate anything that has ever been committed, and turn on secret scanning for every repository. What is DevSecOps? covers the basics.

Repeatable → Measured. Replace long-lived CI cloud keys with OIDC federation and least-privilege roles, pin third-party actions to full-length commit SHAs, and generate an SBOM for every build. See the CI/CD supply-chain playbook.

Measured → Optimizing. Sign what you build and record provenance, then verify both at deploy time with policy as code, so an unsigned or non-compliant artifact cannot reach production. See DevSecOps consulting.

Holding Optimizing. Keep testing the controls, not just running them: check that an unsigned image really is refused, keep dependencies current on a schedule, and measure account posture against a baseline. The DevOps readiness checklist is a quick re-check of the basics.

How the score works

Every answer is worth 0 to 3 points, from least to most mature. Each area has three questions, so each area scores 0 to 9, and the whole assessment 0 to 54.

  • Area level. An area score of 0–2 is Reactive, 3–5 Repeatable, 6–7 Measured and 8–9 Optimizing. The top band is deliberately narrow: Optimizing needs at least two top answers and none below 2.
  • Overall level. The average of the six area levels, rounded down, so a weak area pulls the overall result down. Five areas at Measured and one at Reactive average 2.67, which rounds down to Repeatable. A fast pipeline does not make up for secrets in code or a cloud bill nobody owns.
  • Total score. The result also shows the raw total out of 54. It is useful for tracking change between re-takes, but it does not set the level.
  • Recommendations. The two areas with the lowest scores get the next step for their current level. Ties go to the area listed first.
  • The answer code. Your answers are kept in the page address as an 18-character code, one character per question (0–3, or a dash if unanswered), so a bookmark reopens the same result.

How to use your result

Answer for one system, the product or platform that matters most, rather than averaging across everything you run. If most services deploy daily but the billing service ships once a quarter and that is the one customers notice, answer for billing. Score what is true today, not what is planned.

The result is most useful as a conversation. Ask two or three colleagues to take it separately for the same system and compare: where people disagree on a question, the disagreement usually tells you more than the score. Re-take it each quarter against the same system; the address keeps your answers, so a bookmark is your baseline.

For a concrete list of practices without a score, work through the DevOps readiness checklist. To measure delivery performance rather than self-report it, instrument the five DORA metrics.

Method and sources

This is InfraZen’s own rubric, not a DORA benchmark. It is not a certification, and its scores cannot be compared with DORA’s published research or any industry survey. To compare your delivery performance with the rest of the industry, take the DORA Quick Check.

The questions and levels are informed by public frameworks, each linked to its primary source:

  • Delivery. The three delivery questions use three of DORA’s software delivery performance metrics: deployment frequency, change lead time and failed deployment recovery time. Their answer ranges regroup the six answer options in the DORA Quick Check into four bands. The practices behind several areas also draw on DORA’s capability catalog, which includes continuous delivery, deployment automation, flexible infrastructure, monitoring and observability, and pervasive security.
  • Reliability and alerting. The Google SRE workbook: error-budget policies approved by product, development and SRE (Implementing SLOs), multiwindow, multi-burn-rate alerts (Alerting on SLOs), blameless postmortems with tracked action items (Postmortem Culture), a target of at most two incidents per on-call shift (On-Call) and a 50% limit on SRE operational work (Eliminating Toil).
  • Cost. The FinOps Foundation’s crawl, walk, run maturity model. The allocation question uses its sample goals: at least 70% of cost allocated to a known owner at Crawl, at least 85% at Walk and more than 90% at Run.
  • Platform and self-service. The CNCF Platform Engineering Maturity Model, whose levels run Provisional, Operational, Scalable and Optimizing. Our fourth level shares the name Optimizing but is scored on a different scale.
  • Security. GitHub’s secure use reference, which calls pinning an action to a full-length commit SHA the only way to use it as an immutable release, its guidance on OpenID Connect in place of long-lived cloud secrets, and the SLSA build levels for provenance.

The level names, score bands and the rounded-down overall level are InfraZen’s choices. Both the FinOps and CNCF models warn against treating the top level as a goal everywhere, and so do we: see the FAQ below.

Related: DORA metrics · DevOps readiness checklist · What is DevOps? · What is SRE? · What is FinOps? · What is DevSecOps? · DevOps vs SRE vs platform engineering · Uptime & SLA calculator

faq

Questions about the assessment.

Does this assessment send or store my answers?

No. Your answers are scored in your browser, and this tool never sends or stores them. The answer code sits only in the page address, so you can bookmark or share the result. Like any web address, it appears in our web server's access logs if you reload the page, open a shared link or follow a link from it to another page on this site, and in the contact form's page reference if you choose to send it. There is no signup, and the assessment sets no cookies.

Is this the same as the DORA Quick Check?

No. DORA's Quick Check asks five questions about software delivery performance and compares your team with the rest of the industry. This assessment covers six areas, including reliability, cost and security, and scores them against InfraZen's own rubric. The three delivery questions use answer ranges grouped from the Quick Check's options, but the result is not a DORA benchmark. Use both: the Quick Check for delivery performance, this for the wider picture.

Why does one weak area pull my overall level down?

Because the overall level is the average of the six area levels, rounded down. A fast pipeline does not make up for secrets in code or a cloud bill nobody owns, so the result should not let it. Five areas at Measured and one at Reactive average 2.67, which rounds down to Repeatable. The two weakest areas are also the ones the result tells you to fix first.

What level should my team aim for?

Not necessarily Optimizing everywhere. Each level costs more time and money to reach and hold. The CNCF platform engineering maturity model says reaching the highest level should not be a goal in itself, and the FinOps Foundation says the same of reaching Run in every capability. Aim for Measured in the areas that carry your biggest risk, and move one area at a time, starting with the weakest.

> infrazen assess --review

A score is a start. A plan is the point.

Bring your result to a free 30-minute review with a senior engineer, and leave with an honest view of which weak area to fix first and what that work involves.

Book a free review → Readiness checklist