Organisations talk about autonomous operations as though it were a switch to flip. In reality, the path from manual runbooks to systems that manage themselves is long, incremental, and full of prerequisites that most teams underestimate. This matters for distributed systems because automation that does not account for partial failures, consistency requirements, and observability gaps will create problems faster than it solves them.

This article presents a maturity model for autonomous operations. It defines six levels from fully manual to fully autonomous, describes what each level requires in terms of tooling and process, explains why most organisations stall at the middle levels, identifies the prerequisites for moving forward, catalogues common mistakes, and offers a practical framework for self-assessment.

The maturity levels

A maturity model is only useful if the levels are defined precisely enough that an organisation can determine where it sits today. The following six levels describe a progression in operational autonomy. Each level builds on the capabilities established at the levels below it.

  • Level 0: Manual operationsEverything is done by hand. Runbooks exist (sometimes), and operators follow documented procedures to diagnose and resolve incidents. There is no automated detection. Humans notice problems through user reports or by checking dashboards.
  • Level 1: Alerting and monitoringThe system detects anomalies and notifies operators. Monitoring covers key metrics, and alerts fire when thresholds are breached. Diagnosis and remediation remain entirely manual. This is where structured observability begins.
  • Level 2: Semi-automated remediationSome remediation steps are scripted. An operator triggers a script to restart a service, scale a resource, or clear a queue. The human decides when to act, but the execution is automated. Runbooks reference specific automation scripts.
  • Level 3: Automated with human approvalThe system detects a problem, selects a remediation action, and presents it to a human for approval. The human reviews and confirms before the action executes. This is the first level where the system has decision-making capability, but authority remains with the operator.
  • Level 4: Autonomous with oversightThe system detects, decides, and acts without waiting for approval. Humans monitor outcomes and can intervene if the automated response is incorrect or insufficient. Escalation protocols handle situations the system cannot resolve on its own.
  • Level 5: Fully autonomousThe system operates, remediates, and adapts without human involvement. Humans set policies and review aggregate outcomes but are not in the operational loop. This level is achievable only for well-bounded, thoroughly tested operational domains.

Most production systems today operate somewhere between Level 1 and Level 2. A smaller number reach Level 3 for specific operational tasks. Level 4 and Level 5 remain rare outside of highly constrained environments.

What each level requires

Moving from one level to the next is not primarily a matter of tooling. It is a matter of accumulated capability across observability, testing, process maturity, and governance.

Level 0 to Level 1 requires instrumentation. You need metrics, logs, and traces that cover the critical paths in your system. You need alerting rules that are tuned well enough to surface real problems without generating excessive noise. This is foundational, and it is covered in detail in observability for distributed systems.

Level 1 to Level 2 requires codified knowledge. The remediation steps that experienced operators carry in their heads need to be captured as executable scripts. This sounds straightforward, but it demands that the team understand their failure modes well enough to write deterministic responses to them. The discussion of failure modes, retries, and idempotency is directly relevant here: automated remediation scripts must be safe to re-execute.

Level 2 to Level 3 requires decision logic. The system needs to map observed conditions to remediation actions. This can be rule-based, model-based, or a combination. It also requires a review interface where humans can evaluate proposed actions quickly and approve or reject them. The boundary-setting patterns for agentic systems apply directly to this level.

Level 3 to Level 4 requires trust, earned through extensive testing and production track record. The approval gate is removed for action types where the system has demonstrated consistent correctness. This demands comprehensive test coverage, including chaos engineering and fault injection, to validate that automated responses work under realistic failure conditions.

Level 4 to Level 5 requires formal verification of operational policies, continuous validation of system behaviour against those policies, and governance structures that can audit autonomous decisions after the fact. Very few organisations have the infrastructure or the operational discipline to sustain this level.

Why organisations stall

The most common stall point is between Level 2 and Level 3. Teams have monitoring in place and a collection of remediation scripts, but they cannot make the transition to automated decision-making. There are several recurring reasons.

The first is incomplete observability. The monitoring is good enough for humans to diagnose problems with additional context and intuition, but not structured enough for a decision engine to act on. Metrics are noisy, logs are unstructured, and the correlation between symptoms and root causes is not formalised.

The second is fear of automated action. Operations teams have seen automation go wrong. A misconfigured auto-scaler that burns through a cloud budget in hours. A restart loop that cascades into a wider outage. These experiences create justified caution. Without strong testing and rollback mechanisms, the risk of automated remediation often outweighs the benefit.

The third is organisational inertia. Moving to Level 3 changes the operator's role from executor to reviewer. This requires different skills, different tooling, and different on-call expectations. Teams that are already stretched thin by manual operations rarely have the capacity to invest in the transition.

The fourth is governance gaps. At Level 3, the system is making decisions that previously required human judgment. This raises questions about accountability, audit trails, and compliance that many organisations have not addressed. Regulated industries face additional constraints, as the requirements explored in multi-cloud strategies under regulatory pressures illustrate.

Prerequisites for advancement

Each transition has prerequisites that must be satisfied before the move is safe. Skipping them creates fragile automation that fails in ways that are harder to diagnose and recover from than the original manual process.

For the transition from Level 1 to Level 2, the prerequisites are well-documented failure modes, idempotent remediation procedures, and version-controlled automation scripts with rollback capability.

For Level 2 to Level 3, the prerequisites are structured observability data suitable for programmatic consumption, a decision framework that maps conditions to actions with defined confidence thresholds, a review interface that provides sufficient context for rapid human evaluation, and audit logging for every proposed and executed action.

For Level 3 to Level 4, the prerequisites are extensive production track record demonstrating decision accuracy, fault injection testing that covers the failure scenarios the automation is expected to handle, escalation protocols with defined timeout and fallback behaviour, and governance approval for autonomous operation of each action class.

For Level 4 to Level 5, the prerequisites include formal specification of operational policies as verifiable constraints, continuous validation infrastructure, and a mature incident review process that feeds back into policy refinement. The ideas behind specs, invariants, and contracts are directly applicable here: operational boundaries expressed as enforceable properties rather than informal expectations.

Common mistakes

Several patterns consistently lead to failed automation initiatives. Recognising them early can save significant effort and risk.

  • Automating without understandingTeams automate the remediation steps from their runbooks without first understanding why those steps work. When the failure mode shifts slightly, the automated response does the wrong thing. Automation amplifies both correct and incorrect responses.
  • Skipping the observability investmentAutomation built on top of inadequate observability is blind automation. If the system cannot accurately detect the condition it is remediating, it will act on false positives and miss true failures. The observability layer must be solid before the automation layer is built.
  • Treating all actions as equal riskRestarting a stateless web server is low risk. Triggering a database failover is high risk. Automation initiatives that do not differentiate actions by risk level will either be too cautious for low-risk actions or too aggressive for high-risk ones. The maturity level should vary by action class.
  • Ignoring the human factorsApproval gates that are too frequent cause alert fatigue. Review interfaces that lack context slow decisions. On-call rotations that mix manual and automated incident response create confusion about responsibilities. The human side of automation requires as much design attention as the technical side.
  • No rollback planEvery automated action should have a defined rollback path. If the remediation makes things worse, the system needs to be able to undo what it did. This is especially important for stateful systems where actions have persistent effects.

Practical assessment

Assessing your current maturity level requires honest evaluation across several dimensions. The following questions can guide that assessment.

For each major operational task, ask: Is the detection automated? Is the diagnosis automated? Is the remediation automated? Is the decision to remediate automated? If the answers progress from yes to no as you move through the list, you have a rough indicator of your current level.

Then examine the supporting capabilities. Is your observability data structured and programmatically accessible, or does it require human interpretation? Are your remediation procedures idempotent and tested under failure conditions? Do you have audit trails for automated decisions? Is there a governance framework that defines which actions are approved for automation?

Map each major operational workflow to a maturity level independently. A system might be at Level 3 for horizontal scaling, Level 2 for certificate rotation, and Level 0 for database schema migrations. This granular view is more useful than a single aggregate score.

Finally, identify the binding constraint for each workflow. The constraint is rarely the automation tooling itself. More often, it is observability coverage, testing infrastructure, organisational process, or governance approval. Investing in the actual constraint is more productive than investing in more sophisticated automation on top of an unstable foundation.

The maturity model is not a scorecard for competitive benchmarking. It is a diagnostic tool. It tells you where you are, what you need to get to the next level, and, just as importantly, which levels you do not need to reach. Not every operational task needs to be fully autonomous. The model helps you make that judgment deliberately rather than by default.

Related notes

Back to topic • Back to Notes index