The Observability Maturity Assessment: Where Does Your Team Actually Stand?

The first question I ask on an assessment is never about tools. It is some version of "when the thing you sell breaks at nine on a Tuesday morning, how do you find out, and who decides what to do?" The answer tells me more about a team's real maturity than any list of what they have bought. I have sat with teams who owned every product on the market and still learned about outages from customers, and teams with a modest stack who could name the failing dependency inside a minute. Maturity is not what you have installed. It is what you can actually do when it matters.

That is the honest way to use a maturity model, and it is worth saying up front because most of them get read the wrong way: as a shopping list where each level is another product to buy. It is the opposite. Each level is a description of a capability you either have or you do not, and buying the tool almost never gives you the capability.

A maturity model is a ladder of capability, not of spend. The versions that circulate (AWS publishes a well-known one, and most vendors have a near-identical five-step version) all describe the same journey: from finding out something is wrong, to understanding why, to seeing it coming, to the system handling some of it for you. The labels differ. The shape does not.

What matters is the axis they are measured on. The good models do not score you on how many logs, metrics and traces you collect. They score you on how well that telemetry is correlated, shared across teams, and actually used to make decisions when an incident is live. Collection is table stakes. Use is the thing. A team drowning in dashboards nobody trusts is not more mature than a team with three that they do.

And the gap is worth closing. In one 2026 industry survey, the share of teams describing themselves as mature or expert jumped sharply in a single year, and the mature teams were far more likely to report business and financial impact to their leadership than the early-stage ones. Maturity is not a vanity badge. It is the difference between observability being a cost centre nobody understands and a capability the business can see the value of.

Level one, reactive. You find out something is broken because a customer, or a colleague, tells you. Monitoring exists, but it watches the things that were easy to watch, not the things that break. Every incident is an archaeology dig.

Level two, proactive. You have the golden signals and standardised telemetry, and alerts mostly fire before the customer calls. This is where a lot of competent teams live, and it feels like the finish line. It is not.

Level three, correlated. When something breaks, you can move from symptom to cause without reconstructing the timeline by hand, because your telemetry is joined up across services. This is the level most teams think they are at and most teams are not. The jump from two to three is the hardest and the most valuable one on the ladder.

Level four, predictive. You see some classes of trouble coming: capacity, anomalies, the slow degradations that used to surface as an outage. The system flags them while there is still time to act.

Level five, autonomous and business-aligned. Some remediation happens without a human in the loop, safely and within agreed limits, and the whole thing is expressed in terms the business understands. Very few teams are genuinely here, and the ones claiming it are usually describing a vendor demo, not their Tuesday.

The trap in every self-assessment is that we score the intention, not the reality. So do not ask "do we collect traces?". Ask harder questions, the ones an outside assessor asks:

When your most important service degraded last month, how did you first find out, and how long until someone knew which change caused it? Who decided to roll back, and did they have what they needed to decide, or did they guess? If your best engineer were on leave, would anyone else have found it as fast? And the one that cuts deepest: which of your dashboards did you actually look at during the last incident, and which just exist?

Answer those about a real, recent incident rather than in the abstract, and your true level tends to fall out honestly, usually a notch below where the org chart says you are.

Here is the part vendors are quiet about. A tool can hand you the raw material for a level. It cannot hand you the level. Correlation is a practice as much as a feature: it needs consistent naming, ownership, and the discipline to instrument the things that matter rather than everything. The predictive level needs someone to tune and trust the signals, or they become noise you learn to ignore. You move up the ladder by changing how the team works, and the tool supports that change. Buy the platform and skip the practice, and you get an expensive way to stay at level two.

This is the same pattern as the cost problem. Teams overspend on observability for the same reason they stall on maturity: they treat a capability as a purchase. The fix in both cases is to start from the question you are trying to answer and work back to what you actually need. That is the whole argument of The Observability Cost Conundrum, and it is why cost and maturity are two views of the same discipline.

Pick your most important service. Take the last real incident on it, and walk the four questions above with the people who were there. Do not grade generously. Wherever the honest answer is "we found out late" or "one person carried it", that is your real level, and that is where the next improvement is worth more than any new tool. Write down the one capability that would have changed that incident, and make that the next thing you build.

If you want an outside read, a maturity assessment is exactly the work I do: an honest, tool-agnostic picture of where a team stands and the shortest path to the level that would actually change their incidents and their spend. You can start a conversation about that here, and if you would rather start with the thinking, the free chapter lays out the approach.