Writing SLIs in PromQL

WHAT THIS TESTS Whether you can translate SLO definitions into accurate PromQL, including the correct use of rate over counters and histogram_quantile over bucket series.

A GOOD ANSWER COVERS An SLI is a ratio of good events to valid events; the SLO is the target for that ratio. For availability with a 99.9 percent target, compute the fraction of non-error requests: sum(rate(http_requests_total{status!~"5.."}[28d])) / sum(rate(http_requests_total[28d])). Multiply by 100 to read as a percentage and compare to 99.9. Using rate handles counter resets correctly, and a multi-day window matches the SLO period. For the latency SLI, the 95th percentile under 300ms is computed with histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))), which yields the p95 in seconds; the SLI is met while this is below 0.3. Note the two SLOs use different numbers: 99.9 is the availability target, while 0.95 is the latency quantile, not an availability figure. You must sum by le before applying histogram_quantile so buckets aggregate across instances.

COMMON WRONG ANSWERS Using raw counters instead of rate, which breaks on restarts. Forgetting sum by (le), giving wrong quantiles. Confusing the availability target 99.9 with the latency quantile 95. Filtering 4xx out of total when the SLO counts them as valid.

LIKELY FOLLOW-UPS What counts as a good versus valid event? How do you derive the error budget from this? How does bucket layout affect the 300ms threshold accuracy?

ONE CONCRETE EXAMPLE Availability: sum(rate(http_requests_total{status!~"5.."}[28d])) / sum(rate(http_requests_total[28d])) should be at least 0.999. Latency: histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m]))) should stay below 0.3. Together they assert that 99.9 percent of requests succeed and the p95 response is under 300 milliseconds.