Multi-Dimensional SLOs

Beyond uptime: latency, correctness, freshness.

Dimensions

The classic SLO is a single number: availability. It is also the easiest to measure and the easiest to game. A service that returns 200 OK with stale data, the wrong answer, or a 30 second response time is technically available, but no user would call it healthy. A multi-dimensional SLO closes those gaps by treating reliability as a vector, not a scalar.

The four dimensions worth tracking on every service tier:

• Availability.: The percentage of requests that complete with a non-error status. This is the lowest bar and the easiest to measure, but on its own it is misleading. A 99.9% availability score with 5 second p99 latency is a bad service that looks fine on paper.
• Latency.: The percentage of requests served within a budget (typically p95 or p99 against a fixed millisecond target). Latency captures the slow-but-not-broken failure mode that pure availability misses, especially under load or partial dependency outages.
• Correctness.: The percentage of responses that return the right answer. For a payments API this is reconciliation against the source of truth. For a search API it is relevance against a labeled gold set. Correctness is the hardest dimension to instrument and the easiest one to drop, which is why it gets dropped first.
• Freshness.: For derived data (caches, search indices, replicas, recommendation models), the percentage of reads that see data younger than a max-age budget. A search index that is 12 hours stale technically returns answers, but those answers are wrong in a way that does not show up in availability or latency.

Define each dimension per service, not per team or per platform. The SLO for the checkout API is different from the SLO for the recommendation feed, and rolling them up into one platform number hides exactly the signal you care about.

Compose

Once each dimension is measured separately, the question is how to combine them into a single contractual number. Two patterns work:

• Strict composition.: A request only counts as good if it meets the budget on every dimension. A 2 second response with the right answer is bad if the latency budget is 800 ms. A 200ms response with stale data is bad if the freshness budget is 60 seconds. This is the right model when any single failure mode is user-visible.
• Weighted composition.: Each dimension contributes a fraction to the composite score. Availability might be 50%, latency 30%, correctness 15%, freshness 5%. This is appropriate when the dimensions have different business impact and a partial failure (slow but correct) is genuinely better than a full failure (fast but wrong).

Track both the composite SLO and the per-dimension SLOs. The composite is what you commit to externally. The per-dimension breakdown is what tells you where to invest when the budget burns.

Relax

Not every service needs every dimension at the same strictness. Holding an internal admin tool to the same correctness bar as a payments API is overengineering. The pragmatic move is to tier the strictness per dimension per use case.

• Tier 1 (revenue path).: Strict on availability, latency, and correctness. Freshness optional if the data is not derived. Examples: checkout, billing, auth, payment authorization.
• Tier 2 (user-facing read path).: Strict on availability and latency. Loose on correctness and freshness within bounded windows. Examples: search, recommendations, dashboards, profile pages.
• Tier 3 (internal tools).: Strict on availability only. Latency and correctness budgets are advisory rather than hard. Examples: admin consoles, internal reporting, employee self-service.

The point of the multi-dimensional model is not to add four SLOs to every service. It is to be honest about which dimensions matter for each service and stop pretending availability alone is enough. Nova AI Ops tracks all four dimensions per service, computes the composite and per-dimension scores in real time, and alerts on burn rate before any single dimension exhausts its budget. That is the level of observability multi-dim SLOs need to actually drive engineering decisions instead of sitting in a doc.