A product can meet every internal service objective and still disappoint users because the journey crosses a payment processor, identity provider, messaging service, managed database, or another team’s API. Dependency SLOs are the missing input. They describe how much dependable service a path can reasonably inherit, where the product is exposed to a supplier’s behavior, and which product promises require an engineered fallback rather than confidence in a contract.
The useful question is not whether a vendor advertises 99.9% availability. It is whether a named user journey succeeds within its own latency and correctness boundaries when all required calls, retry behavior, capacity limits, maintenance windows, and recovery mechanisms are considered. That framing turns reliability from an infrastructure percentage into an explicit product risk that product managers and service owners can accept, reduce, transfer, or avoid.
Model the user journey, not the vendor list
Start with critical flows such as sign-in, checkout, account recovery, or report submission. Draw each synchronous dependency on the success path and each asynchronous dependency that must complete before the user outcome is true. Mark whether the call is mandatory, optional, cached, queued, duplicated across providers, or replaceable by a reduced experience. A dependency used only by recommendations should not consume the checkout availability target if recommendations can disappear cleanly.
Define an SLI at the consumer boundary. A provider may report that its endpoint was up while your region could not reach it, your credential quota was exhausted, or its response arrived after your journey deadline. Measure eligible requests from the product’s point of view: valid responses, completed transactions, or durable acceptance within a threshold. Keep provider status and SLA data as supporting evidence, not as a substitute for consumer-observed behavior.
| Dependency role | Reliability treatment | Evidence to retain | Product decision |
|---|---|---|---|
| Hard synchronous call | Include in path model and latency budget | Consumer-side success, timeout, and error distribution | Fund redundancy or accept the ceiling |
| Optional enrichment | Fail open without blocking the core result | Rate of omitted or stale enrichment | Define an acceptable degraded experience |
| Queued side effect | Acknowledge durable acceptance, then track completion | Queue age, dead letters, and completion lag | State how late is still useful |
| External provider | Measure independently and compare with contract | Status events, support records, quota and regional errors | Set escalation and exit triggers |
Use composite availability as a scenario, not a prophecy
For independent serial components, multiplying availability estimates is a useful first-order model. A path that requires three components, each estimated at 99.9%, has a modeled success probability of about 99.7% before application errors are counted. The arithmetic exposes why adding mandatory calls can lower the attainable journey target. It is not a forecast: failures are rarely independent, measurements use different exclusions, and shared networks, regions, credentials, and deployments create correlated risk.
Parallel redundancy uses different reasoning. Two equivalent providers help only when the product can detect failure, route safely, reconcile side effects, and avoid a common failure domain. A fallback that depends on the same cloud region, DNS path, secret store, or client library is less independent than the diagram suggests. Model scenarios explicitly: provider unavailable, provider slow, quota exhausted, malformed response, partial regional impairment, and both providers reachable but inconsistent.
Use ranges rather than false precision. Record a baseline from observed consumer-side data, a contractual floor where one exists, and a stress case based on incidents or plausible common-mode failures. Review the range with product owners. The value of the model is the decision it forces: change the promise, remove the dependency from the critical path, add a fallback, or consciously carry the exposure.
Build a dependency risk budget for each critical flow
Translate each journey objective into an error budget and allocate exposure categories without pretending they are organizational entitlements. For a 99.9% monthly objective, the budget is the permitted proportion of unsuccessful eligible events, not a bucket of minutes assigned mechanically to every supplier. Track how much loss comes from your code, internal dependencies, external providers, planned change, bad input classification, and ambiguous telemetry. This separates controllable engineering work from residual product risk.
Do not double-count one incident across every layer. The product SLI records the user impact once; dependency attribution explains cause. Preserve both views. A provider failure may consume the product budget, the consumer service budget, and an internal API budget in their respective reports, but portfolio decisions should understand that these are nested observations of one event rather than additive business loss.
| Risk budget field | Practical definition | Review trigger | Likely action |
|---|---|---|---|
| Journey objective | Success threshold and measurement window | Target no longer reflects user need | Renegotiate promise and SLI |
| Dependency contribution | Consumer-visible bad events attributed to one dependency | Contribution exceeds agreed tolerance | Improve client controls or escalate provider |
| Fallback coverage | Share of dependency failures producing an acceptable result | Coverage or correctness falls | Repair fallback and exercise it |
| Residual risk | Exposure remaining after funded controls | Business impact or likelihood changes | Accept, transfer, reduce, or avoid |
| Uncertainty | Events that cannot be confidently classified | Unknown bucket grows | Fix telemetry before changing targets |
Close the gap between an SLA and the product promise
An SLA is a commercial commitment with definitions, exclusions, claim procedures, and usually service credits. An SLO is an operating target. Compare the two line by line: eligible traffic, regional scope, maintenance, latency, support response, data durability, quota changes, incident notification, and evidence access. Credits rarely compensate for lost customer trust, and an SLA can be met while a particular workflow fails. The review should identify the engineering and product controls needed beyond the contract.
Give every critical dependency an owner and a decision record. Record why it is needed, alternatives considered, data and security constraints, observed SLI, contract renewal date, fallback owner, and exit difficulty. Revisit the record when usage or architecture changes. A provider that was once optional can silently become critical as teams add features, remove local caches, or allow a queued process to become synchronous.
Engineer fallbacks with bounded semantics
A fallback must state what remains true. Serving cached inventory may preserve browsing but cannot promise current stock. Queueing a payment request may be unsafe if the customer interprets it as a completed purchase. Switching identity providers may change assurance level or account linking. Write the degraded contract in user terms, including freshness, reversibility, duplicate handling, security, and the point at which the product must stop rather than return a misleading success.
Test fallback activation and recovery. Circuit breakers, timeouts, retry budgets, bulkheads, stale reads, alternate providers, and queues all have state. Observe false activation, time to enter degraded mode, capacity while degraded, and time to restore normal behavior. Recovery can be more dangerous than failure if queued work floods a dependency or two systems both apply a side effect. Rate-limit replay and make write operations idempotent where retries are permitted.
Make residual risk a product acceptance
Present dependency risk in a product review with four choices: accept the current exposure, reduce it through engineering, transfer part of it through commercial terms or insurance, or avoid it by changing the feature. Include user impact, observed frequency, plausible worst case, control cost, and uncertainty. Avoid a red-amber-green score without evidence. A low-frequency dependency may still deserve work if failure blocks a regulated deadline or produces irreversible financial state.
Tie the decision to an error budget policy. Repeated dependency-caused budget consumption should trigger predefined action such as freezing expansion of the affected path, running a provider review, funding a fallback, or changing the product target. The policy should not punish the team for a supplier event it cannot prevent; it should ensure the organization responds to recurring exposure rather than normalizing it.
Key takeaways
- Measure dependency reliability at the consumer boundary and against a named user journey.
- Use serial and redundant availability formulas to expose assumptions, then test correlated failure scenarios.
- Separate product impact from causal attribution so one incident is not added repeatedly.
- Specify degraded semantics, activation, capacity, and recovery before calling a fallback reliable.
- Ask product owners to accept residual exposure with evidence and a review date.
Frequently asked questions
Can a vendor SLA be used as its dependency SLO?
Use it as one input, not the operating measure. Contract definitions may exclude events your users experience, and they usually do not represent your network path, quotas, credentials, integration defects, or journey latency. Maintain a consumer-observed SLI and reconcile material differences with provider reports.
Should teams multiply every component SLO?
Only for a clearly defined serial path and as an approximation. Optional calls, asynchronous completion, fallbacks, correlated failures, and mismatched measurement windows make simple multiplication misleading. Prefer a journey model with scenarios and observed end-to-end data.
Who owns third-party reliability risk?
Engineering owns integration controls and evidence; procurement or legal owns contractual mechanisms; product leadership owns the customer promise and residual business exposure. One named dependency owner should coordinate those responsibilities without pretending to control the provider.
Conclusion
Dependency SLOs become useful when they change a decision. Measure the user journey, model hard and soft dependencies, test common-mode failure, and price the remaining uncertainty in product terms. That work reveals which promises are supported by architecture, which rely on fallbacks that need proof, and which risks leadership has deliberately chosen to carry.