Standard : Monitoring is aligned to business and customer outcomes, not just technical signals
Purpose and Strategic Importance
Monitoring and observability practices have historically been designed for operations teams — measuring infrastructure health, CPU utilisation, memory usage, and service uptime. While these signals are necessary, they are insufficient. A server can be running perfectly while customers are experiencing failed transactions, slow checkouts, or broken user journeys. This standard establishes that monitoring must be anchored to what customers and the business actually care about: whether users can complete their goals, whether revenue-generating flows are functioning correctly, and whether the organisation can detect and respond to degradations that affect outcomes before they escalate into incidents.
Aligning monitoring to business and customer outcomes transforms observability from a reactive operations tool into a proactive product intelligence capability. When teams instrument against Service Level Indicators (SLIs) tied to user experience — such as the percentage of checkout completions, the latency users experience on critical pages, or the error rate visible to end users — they gain the ability to prioritise work, justify investment, and communicate system health in a language that business stakeholders understand. This standard supports the transition from "the servers are fine" to "our customers are succeeding", enabling engineering teams to demonstrate value, not just availability.
Strategic Impact
- Teams can detect customer-impacting degradations that are invisible to infrastructure-only monitoring, reducing mean time to detection (MTTD) for user-facing failures and enabling faster, more targeted incident response.
- Product and engineering conversations shift from technical jargon to shared outcome metrics, improving alignment between delivery teams and business stakeholders and enabling evidence-based prioritisation of reliability investment.
- SLOs tied to business outcomes create a principled framework for reliability decision-making — allowing teams to defend error budgets, justify toil reduction work, and make conscious trade-offs between feature velocity and service stability.
- Monitoring data becomes an input to product decisions, not just operational dashboards, enabling teams to identify friction points in user journeys, quantify the business impact of technical debt, and measure the effect of releases on customer experience.
Risks of Not Having This Standard
- Engineering teams report green infrastructure dashboards while customers experience silent failures, broken flows, or degraded performance, leading to churn and reputational damage that is discovered too late.
- Without SLOs tied to user outcomes, incident prioritisation is driven by technical severity rather than business impact, causing teams to focus on low-value alerts while high-impact customer issues go undetected.
- Product stakeholders and engineering teams operate with different definitions of "working", creating misalignment, mistrust, and friction when communicating system health to leadership or customers.
- Teams accumulate monitoring debt — large volumes of technical alerts with no clear connection to customer impact — resulting in alert fatigue, reduced signal-to-noise ratio, and slower incident response.
- The organisation loses the ability to quantify the value of reliability investment, making it difficult to justify platform work, SRE resourcing, or infrastructure improvements in business terms.
CMMI Maturity Model
Level 1 – Initial
| Category |
Description |
| People & Culture |
Teams monitor infrastructure and application logs reactively, with no shared understanding of what "good" looks like from a customer or business perspective. |
| Process & Governance |
There are no defined SLIs or SLOs; alerting thresholds are set arbitrarily based on technical intuition rather than user impact. |
| Technology & Tools |
Monitoring is limited to server-level metrics such as CPU, memory, and disk; no user journey or business transaction instrumentation exists. |
| Measurement & Metrics |
Uptime and server health are the primary reported metrics; there is no visibility into customer-facing error rates, latency, or transaction success rates. |
Level 2 – Managed
| Category |
Description |
| People & Culture |
Some teams have begun connecting technical monitoring to user-facing outcomes, but practices are inconsistent across the organisation and driven by individual initiative. |
| Process & Governance |
Basic SLIs are defined for critical user journeys on at least some services, but SLOs are informal and not consistently reviewed or enforced. |
| Technology & Tools |
Application Performance Monitoring (APM) tools are in use, providing transaction traces and basic user-facing latency metrics alongside infrastructure monitoring. |
| Measurement & Metrics |
Error rates and response times are tracked for key endpoints, but these are reported in technical terms and not yet mapped to specific business outcomes or KPIs. |
Level 3 – Defined
| Category |
Description |
| People & Culture |
Engineering teams, product managers, and SREs collaborate to define SLIs and SLOs for all critical user journeys, with shared ownership of reliability targets. |
| Process & Governance |
A formal process exists for defining, reviewing, and updating SLOs; error budgets are tracked and used to inform decisions about feature work versus reliability investment. |
| Technology & Tools |
Golden signals (latency, traffic, errors, saturation) are instrumented for all customer-facing services, and user journey monitoring covers key business transactions end-to-end. |
| Measurement & Metrics |
Business outcome metrics — such as checkout completion rates, failed payment percentages, and user-visible error rates — are published alongside technical metrics in shared dashboards. |
Level 4 – Quantitatively Managed
| Category |
Description |
| People & Culture |
Reliability is treated as a product feature, with SLOs embedded in product roadmaps and engineering teams held accountable for customer outcome metrics alongside delivery velocity. |
| Process & Governance |
SLOs are formally linked to business KPIs, reviewed in regular business rhythm meetings, and inform capacity planning, on-call investment, and release gating decisions. |
| Technology & Tools |
Real user monitoring (RUM), synthetic monitoring, and distributed tracing are combined to provide a complete picture of customer experience from browser to backend. |
| Measurement & Metrics |
Statistical baselines and anomaly detection are applied to business outcome metrics, enabling proactive alerting on deviations before customers report issues. |
Level 5 – Optimising
| Category |
Description |
| People & Culture |
The organisation continuously improves its observability maturity by learning from incidents, refining SLIs based on new customer insights, and sharing practices across teams and domains. |
| Process & Governance |
Monitoring standards are reviewed and evolved as the product and customer base change; SLOs are automatically adjusted based on business context such as seasonal peaks or new markets. |
| Technology & Tools |
Observability platforms provide predictive insights, correlating business metrics with deployment events and infrastructure changes to surface risks before they affect customers. |
| Measurement & Metrics |
Monitoring data feeds directly into product analytics and business intelligence, enabling closed-loop learning where reliability insights inform feature prioritisation and investment decisions. |
Key Measures
- Percentage of critical user journeys with defined SLIs and active SLO tracking, targeting 100% coverage of revenue-generating flows.
- Error budget consumption rate per service per month, with breach events triggering a formal review of reliability investment.
- Mean time to detection (MTTD) for customer-impacting incidents, measured from the point of degradation to the point of alert firing.
- Ratio of customer-reported issues to proactively detected issues, indicating the effectiveness of monitoring coverage relative to user impact.
- Percentage of post-incident reviews that identify a monitoring gap as a contributing factor, used to drive targeted observability improvements.
- Coverage of golden signals (latency, errors, traffic, saturation) across all production services exposed to end users or downstream consumers.