Dependencies and multi-service SLOs
How to think about SLOs when your service calls others — and when platform SLIs matter.
Few services are islands. Dependency failure shows up in your SLI whether or not you “own” the dependency.
Customer-facing SLOs still win
Users experience the edge journey (checkout, search, login). That journey SLO is the north star. Internal service SLOs support diagnosis and ownership — they do not replace the edge.
Count what you promise
If your API fails because a dependency timed out, those requests usually still count against your availability SLI. Excusing them in the formula hides user pain. Use dependency SLIs to drive vendor/platform pressure, not to zero your own burn.
Avoid countdown chains
Five services each at 99.9% do not compose to 99.9% for the user. Design fewer synchronous hops, degrade gracefully, and set journey SLOs that reflect the real graph.
Platform vs product
Platform may offer shared SLIs (Ingress success, cluster scheduling). Product still owns journey SLOs. Blurry ownership produces “not my alert” during incidents.
Async boundaries
For event-driven paths, prefer freshness/completeness SLIs over pretending every hop is a synchronous availability chain. Lag against a business deadline is often the honest signal.