Aggregate event counts before division. Averaging per-instance percentages gives an idle instance the same influence as a busy one.
SLO Error Ratio
An SLI is valid only when errors and totals describe the same event population.
sum(rate(http_requests_total{service="api",code=~"5.."}[5m]))
/
sum(rate(http_requests_total{service="api"}[5m]))
-- Alert with both a fast and slow burn window to control noise.Invariant: Errors and total requests cover the same population and time window.
Use when: You need a traffic-weighted availability signal rather than an average of percentages.
Why this boundary matters
Averaging percentages weights idle and busy instances equally. Aggregating event rates first preserves the traffic-weighted user outcome.
Failure policy
| Boundary | Action |
|---|---|
| 5xx response in the SLI population | Count in both error and total series |
| Excluded request class | Exclude it consistently from numerator and denominator |
| No traffic | Treat the ratio as absent, not perfect availability |
| Labels differ between terms | Fix the query before alerting |
| Low traffic window | Use longer windows or event-count safeguards |
Trade-offs
A ratio is traffic-weighted and honest at scale, but low-volume services produce noisy percentages. Aggregation can hide one tenant or region, while excessive labels make metrics expensive.
Decision rule: Use an error ratio when the numerator and denominator describe the same user-visible population and enough events exist to support the conclusion.