0 / 24

Model 39 of 74 · Technology & Data

Observability & SRE Maturity Assessment

Assess how well your organisation understands, measures, and improves the reliability of its services.

Pillars & areas

Measure

Define what good looks like

  1. 01Service Level Objectives
  2. 02Telemetry & Instrumentation

Observe

Understand what's happening

  1. 03Alerting & On-Call
  2. 04Incident Response & Learning

Improve

Learn and get better

  1. 05Toil & Capacity
  2. 06Reliability Culture & Release Safety

Levels

  1. 1Blind SpotsUsers find problems first
  2. 2MonitoredMeasured & managed
  3. 3Reliability-EngineeredObjective-driven & resilient

01 Service Level Objectives

Are reliability targets defined in terms users care about, and do they guide decisions?

0/4 answered

SL-1How are reliability targets defined for your services?

Think about whether you have explicit, measurable targets for things like availability, latency and correctness.

SL-2How well do your reliability measures reflect what users experience?

Consider whether you measure from the user's point of view (requests succeeding, pages loading) or only server health.

SL-3How do reliability objectives influence decisions about change?

Think about whether teams slow down risky releases when reliability is poor, or keep shipping regardless.

SL-4How is reliability reported?

Consider who sees reliability data and whether it leads to action.

02 Telemetry & Instrumentation

Do teams have the metrics, logs and traces they need to understand how their systems behave?

0/4 answered

TI-1What telemetry do your services produce?

Think about metrics, logs and distributed traces, and whether they cover all important services.

TI-2How easily can teams investigate problems they have never seen before?

Consider whether teams can answer new questions about system behaviour from existing data, or need to add logging and redeploy.

TI-3How consistent is instrumentation across services?

Think about whether services use common standards for naming, formats and context, so data can be compared and combined.

TI-4How are the cost and retention of telemetry managed?

Consider whether telemetry volumes and costs are understood and balanced against their value.

03 Alerting & On-Call

Do alerts reliably signal real problems, and is on-call sustainable for the people who carry it?

0/4 answered

AO-1How useful are your alerts?

Think about how many alerts are false alarms, and whether alerts reflect problems users would notice.

AO-2How are alerts routed and escalated?

Consider whether alerts reach the right person quickly, and what happens if they don't respond.

AO-3What guidance do responders have when an alert fires?

Think about whether each alert links to information on what it means and what to do.

AO-4How sustainable is on-call?

Consider how often people are woken at night, how rotas are shared, and whether on-call load is monitored.

04 Incident Response & Learning

Are incidents handled calmly and effectively, and do they lead to lasting improvement?

0/4 answered

IL-1How are incidents coordinated?

Think about whether there are clear roles during incidents, or whether everyone jumps in at once.

IL-2How are stakeholders and users kept informed during incidents?

Consider internal stakeholders, customer support and affected users.

IL-3How are incidents reviewed?

Think about whether reviews focus on blame or on understanding how the system and organisation allowed the incident.

IL-4How are improvement actions from incidents followed through?

Consider whether actions from reviews are completed, and whether similar incidents stop happening.

05 Toil & Capacity

Is repetitive operational work kept low, and is capacity planned ahead of demand?

0/4 answered

TC-1How much repetitive manual work do operations involve?

Think about manual, repetitive tasks such as restarts, data fixes, provisioning and routine requests — work that adds no lasting value.

TC-2How are routine operational requests handled?

Consider whether other teams must raise tickets and wait for routine operations, or can safely do them themselves.

TC-3How is capacity planned?

Think about whether you know how much load your services can handle and when you will need more.

TC-4How are performance and load tested?

Consider whether you know how services behave under peak or unusual load before it happens in production.

06 Reliability Culture & Release Safety

Is reliability a shared responsibility, and are changes released safely?

0/4 answered

RC-1Who is responsible for reliability?

Think about whether reliability is someone else's problem for development teams, or shared by those who build and run services.

RC-2How are changes released to production safely?

Consider gradual rollouts, quick rollback and monitoring of each release.

RC-3How is resilience tested?

Think about whether you deliberately test how systems cope with failures such as lost servers, slow dependencies or regional outages.

RC-4How is reliability considered when designing new services?

Consider whether reliability requirements, failure modes and observability are thought through at design time.

Self-assessment report

Observability & SRE

Answer the questions above and your report builds here: an overall score, a score and target for each area, and the three changes that matter most.

About this model

About the Observability & SRE maturity model

Customers judge a digital service by whether it works when they need it. Yet many organisations only find out their services are struggling when customers complain, and their engineers spend nights firefighting the same problems again and again. Monitoring dashboards multiply, alerts fire constantly, and nobody can say with confidence how reliable the service actually is or whether it is getting better.

This model assesses reliability engineering and observability as a combined discipline: setting reliability goals that reflect what users experience, collecting the telemetry needed to understand behaviour, alerting people only when it matters, responding to and learning from incidents, reducing repetitive operational work, and balancing the pace of change with stability. It draws on ideas popularised by site reliability engineering but does not require a dedicated SRE team — the practices apply to any team that runs services others depend on.

The Observability & SRE maturity model contains 24 questions across 6 areas: service level objectives, telemetry and instrumentation, alerting and on-call, incident response and learning, toil and capacity, and reliability culture and release safety. Each question describes three levels of maturity through observable practices. It goes deeper than the monitoring area of the DevOps / CI-CD model and complements IT Service Management, which covers service management processes more broadly.

Who this assessment is for

  • SRE, platform and infrastructure teams
  • Engineering managers and heads of engineering
  • Development teams that run their own services in production
  • Operations and IT service management leaders
  • CTOs and product leaders responsible for service reliability

The three maturity levels

  • Level 1 — Blind Spots: Teams often learn about problems from customers. Monitoring covers infrastructure basics but not what users experience, alerts are noisy or missing, and on-call is exhausting. Incidents are handled by whoever knows the system best, root causes are rarely addressed, and nobody can say how reliable services actually are. Reliability competes with features and usually loses until something breaks badly.
  • Level 2 — Monitored: Critical services have defined reliability targets based on user-facing measures. Metrics, logs and traces give teams good visibility, alerts are tied to symptoms users would notice, and on-call is organised and sustainable. Incidents follow a defined process with blameless reviews, and repetitive operational work is tracked and reduced.
  • Level 3 — Reliability-Engineered: Reliability is treated as a feature that users value and the business plans for. Service level objectives guide decisions about when to ship and when to invest in stability, and teams can answer new questions about system behaviour without deploying new code. Incidents are handled calmly and lead to systemic improvement, toil is kept low, and releases are safe by design. Reliability improves steadily while delivery stays fast.

The 6 areas assessed

1. Service Level Objectives

How reliability goals are set and used. This area covers the definition of service level indicators and objectives, the link between objectives and user experience, the use of error budgets or similar mechanisms to balance change and stability, and how reliability is reported.

2. Telemetry & Instrumentation

The data teams use to understand systems. This area looks at the coverage of metrics, logs and traces, the ability to investigate new and unexpected problems, consistency of instrumentation across services, and the cost and retention of telemetry.

3. Alerting & On-Call

How people are alerted to problems and how on-call is organised. This area covers alert quality, routing and escalation, runbooks, and the sustainability of on-call for engineers.

4. Incident Response & Learning

How incidents are managed and learned from. This area covers incident roles and coordination, communication during incidents, post-incident reviews, and how actions and learning are followed through across the organisation.

5. Toil & Capacity

How operational workload and system capacity are managed. This area covers the measurement and reduction of toil, self-service for routine operations, capacity planning, and performance and load testing.

6. Reliability Culture & Release Safety

How reliability is embedded in culture and delivery. This area covers shared ownership of reliability between development and operations, safe release practices, resilience testing, and how reliability is considered in design.

How this model relates to other frameworks

This is an original, simplified maturity model and is not derived from or intended to replace any of the following. However, organisations that use this assessment may also find value in these established frameworks:

  • Google Site Reliability Engineering books — influential publications that popularised SRE practices such as SLOs and error budgets
  • OpenTelemetry — an open standard for generating and collecting telemetry data
  • DORA research and metrics — research on software delivery and operational performance
  • ITIL 4 — a service management framework that includes incident and problem management practices

Frequently asked questions

What is the Observability & SRE maturity model?

Assess how well your organisation understands, measures, and improves the reliability of its services. It is an original, simplified model with three maturity levels (Blind Spots, Monitored and Reliability-Engineered), assessed through 24 questions across 6 areas: Service Level Objectives, Telemetry & Instrumentation, Alerting & On-Call, Incident Response & Learning, Toil & Capacity and Reliability Culture & Release Safety.

How long does the Observability & SRE assessment take?

Most people finish in 10–14 minutes. Each of the 24 questions has three concrete answer options. Your progress is saved in the page URL, so you can bookmark it and come back later.

How is the score calculated?

Each answer scores 1 (Blind Spots), 2 (Monitored) or 3 (Reliability-Engineered). An area's score is the average of its answered questions, and the overall score is the average of the area scores, so every area counts equally. Scores run from 1.0 to 3.0.

Is my data stored or shared?

No. Your answers are never sent to a server. They are stored only in the page URL, which you control. Copy the link to share results with colleagues, or export a PDF or CSV report.

How should I use the results?

Start with "Where to focus" in your report. It lists the questions with the biggest gap to the target you set for each area, and shows what the next level looks like in practice. For a fuller picture, ask several people from different teams to complete the assessment and compare their links. Differences in perception are often as revealing as the scores themselves.