SLOs for infrastructure teams whose users are other teams

Why product-SLO thinking breaks for platforms

Article 17’s mechanics quietly assume a product’s shape: one service, one kind of user, one golden signal. A platform has none of those. Your fifty internal teams each experience your “service” through a different door — one lives or dies on DNS latency, another on terraform apply time, another on NAT throughput. There is no single golden signal to pick; there are as many as there are capabilities you expose. And there’s a second twist a product team never faces: your consumers stack their own SLOs on top of yours. Your reliability isn’t the top of anyone’s stack — it’s an input to fifty other reliability numbers, and a miss you barely notice propagates upward into pages you’ll be blamed for. The reframe that makes the rest tractable: you are not measuring a service. You are measuring an interface between teams.

Identify the actual consumer

So the first question isn’t “what’s our SLI” — it’s “whose experience are we on the hook for?” Infrastructure comes in layers, and each layer is the consumer of the one below: the app team consumes the platform, the platform consumes the network, the network consumes the telco. The trap is reaching too far up. You cannot own an SLO for an outcome three layers above you — you don’t control the app’s retry logic or the user’s Wi-Fi, and you can’t be paged for them. Your SLI lives at your interface.

The concrete method: stop saying “the platform” and enumerate the capabilities you expose — DNS resolution, egress connectivity, cluster provisioning, pipeline execution — and treat each as a separately measurable contract. A platform doesn’t have an SLO. It has one per capability, each with its own consumer, boundary, and number.

The responsibility boundary

When an app is slow, is it the app, the mesh, the network, or DNS? Everyone points at everyone, and the argument is unwinnable because nobody has a measurement scoped to what they actually own. An infrastructure SLO is only defensible if it measures precisely what you control — and the whole game is choosing the measurement point. Take the hybrid-DNS SLI from Article 17, “query success within 100 ms.” Measure it at the client, and your number folds in the on-prem forwarder and the client’s stub resolver — components you don’t own, whose failures you’ve now signed up for. Measure it at the Route 53 Resolver endpoint, and the number reflects exactly your responsibility and nothing else.

Two consequences follow. First, shared fate: you run on top of AWS’s SLA, so your SLO must be looser than the composite of what you depend on — Resolver × Direct Connect × on-prem — because you cannot be more reliable than the floor you stand on. (That’s Article 17’s dependency math, now pointed at your dependencies.) Second, and more valuable politically: a well-placed SLI turns “the network is slow” from an argument into a measurement. When the DNS SLO is green and measured at your endpoint, “DNS is the problem” becomes a claim someone has to disprove with data. The boundary is where blame stops being a meeting and becomes a number.

The infrastructure SLI menu

With the boundary drawn, what do you actually measure? Three families — plus one almost everyone forgets.

Availability of the capability — can a team resolve, connect, provision at all. Latency of the capability — provisioning time, DNS p99, pipeline duration (a percentile, never an average — see Article 17). Correctness or change quality — did a change to shared infra break its consumers, which ties straight to change failure rate. And the one platform teams routinely miss: provisioning SLOs. “A new VPC, account, or cluster is ready in N hours” is very often the number your internal customers care about most — it’s the difference between a team shipping this sprint or next — and almost nobody publishes it. Time-to-ready is the most visible promise a platform makes and the least measured.

The negotiation

Here the two worlds diverge hardest. A product SLO is set from user data — you measure what users tolerate and pick a target under it. An infrastructure SLO is negotiated with the consumer teams, which makes it a political document as much as a technical one. Start every negotiation with one question: “what do you assume about us today?” The answer, nine times in ten, is 100% — teams have quietly architected against a guarantee you never made, with no retries, no caching, no failover, because they assumed you’d never be down. Surfacing that is half the value before you’ve set a single number. Then publish the SLO explicitly, so teams design for the real figure instead of an imaginary one. And ask the tiering question: do all fifty teams get the same SLO, or do Tier-1 workloads get a tighter one — at a chargeback price? That last move is where a platform SLO becomes a product-management instrument: differentiated tiers, differentiated cost, connected to unit economics. You’re no longer running a service; you’re pricing one.

Error budgets when your consumers cause the burn

Now the asymmetry product teams never face: your consumers can spend your error budget. A runaway workload saturates the NAT; a bad deploy hammers the resolver. The burn is real, the budget is yours, and the fault is theirs.

Two things follow. First, defend the budget: per-tenant SLIs plus quotas turn “one team can take down the shared capability” into “one team can only spend its own share.” The quota is a budget-protection mechanism, not just a rate limit. Second, the policy question: does a consumer-caused burn trigger your change freeze? No — freezing your releases doesn’t fix their runaway, and it punishes the platform for a fault it didn’t commit. But that answer only holds if your telemetry can attribute the burn: you must be able to say whose traffic spent the budget. Per-consumer attribution — the multi-tenant observability problem — is what lets you route the consequence to the right team instead of eating it yourself. Without it, every burn looks like your fault, and you’ll freeze for things you didn’t do.

Anti-patterns

The failure modes are consistent enough to name and avoid.

Worked example: hybrid DNS as a platform contract

Put it together on one capability — the hybrid-DNS resolution from Article 17, taken up a level. Six steps, one page.

That’s the whole contract — one page. Notice what happened: the Article 17 mechanics didn’t change at all. What changed was everything around them — who the consumer is, where the boundary sits, who can burn the budget. That’s the pattern for every platform SLO, and it’s the meta-lesson of the series: the framework isn’t replaced as you go up a level. It compounds.