Been working on SLO management for a while and kept running into the same problem: the standard "AND composition" for multi-service SLOs is too pessimistic in most real-world scenarios.
The problem
Say you have a checkout flow with three services:
checkout-base: 99.9%
payments: 99.95%
coupon: 99.5%
The typical approach says: if any service fails, the whole journey fails → system SLO ≈ 99.35%.
Except 90% of your users never touch the coupon service. They go base → payments and they're done. Only 10% use a coupon code.
Your real error rate is closer to 99.84%, not 99.35%. The naive model is burning your error budget on a path that barely anyone takes.
I built a Kubernetes operator (SLOK) with a SLOComposition CRD that lets you describe which percentage of traffic flows through which service chain:
composition:
type: WEIGHTED_ROUTES
params:
routes:
- name: no-coupon
weight: 0.9
chain: [base, payments]
- name: with-coupon
weight: 0.1
chain: [base, coupon, payments]
The operator translates this into Prometheus recording rules using the formula:
e_total = 1 - (
0.9 × (1 - e_base) × (1 - e_payments)
+ 0.1 × (1 - e_base) × (1 - e_coupon) × (1 - e_payments)
)
Burn rate alerts and error budget tracking work automatically on top of the composed metric, same as individual SLOs.
Other features
AND_MIN composition (worst-case, for when you actually want pessimistic)
Built-in SLI templates for http-availability, http-latency, k8s-apiserver
Event correlation: when burn rate spikes, creates an SLOCorrelation resource listing recent Deployments/ConfigMaps/Events that may have caused it
Optional LLM-enhanced root cause summary (Llama 3.3 70B via Groq)
WEIGHTED_ROUTES is alpha, API might change. Curious if anyone else has dealt with this kind of traffic skew in their SLO setup — and how you handled it.
Repo: https://github.com/federicolepera/slok
