When defining an availability SLI for an HTTP API, which responses should count as bad — and do 4xx errors, rate-limit 429s, health checks and bot traffic belong in the denominator?

## Why classification is the real work An availability SLI is a ratio, and the interesting decisions are all about **which events go in the denominator and which of those count as bad**. Two teams can compute "availability" for the same service and differ by a full percentage point purely through classification. Because a target is only meaningful against a definition, the classification *is* the service level. Start from the anchor points nobody argues about: a 5xx response is a bad event; a 2xx or 3xx is a good one. Everything else needs a decision with a stated reason. ## Health checks, probes and internal traffic These must come out of the denominator, and the reason is quantitative. A service receiving 20 real requests a minute may receive 200 liveness and readiness checks a minute from its scheduler, plus uptime probes and mesh health checks. If those are in the denominator and the shallow health endpoint keeps returning 200 while the real dependency is dead, the ratio during a **total** functional outage sits above 90%. The indicator has been diluted by traffic that has no user behind it. The same argument applies to internal cache warmers, load-test traffic against production, and your own synthetic probes if they share the ingress path. Filter them by path, by user agent, or better, by an explicit header or client identity so the exclusion cannot be spoofed by accident. ## Bot, scanner and abusive traffic Security scanners generate large volumes of requests to paths that do not exist, producing 404s, and occasionally trip real 5xx paths in code nobody meant to expose. Crawlers hit expensive endpoints at odd hours. Including them means your reliability number partly describes your experience of being scanned. Exclude them where you can identify them, and accept that identification is imperfect. ## The 4xx family The default is that a 4xx is not a service failure — the client sent something invalid, and a service correctly rejecting it is behaving well. Two exceptions matter in practice: - **You caused it.** A schema change, a stricter validator, or a new required header shipped in your deploy turns previously valid requests into 400s. Users experience a broken product; your availability indicator reports perfection. This is the most common way an outage hides from an SLI. - **Authentication and authorisation.** A 401 or 403 storm caused by an expired signing key, a clock skew, or a broken token service is your outage, delivered as a client-error status code. Two workable responses: either count a specific subset (401/403, and 400 above a baseline) as bad, or keep 4xx out of the availability indicator and cover it with a separate quality indicator that watches the 4xx *rate* against its own baseline. The second is cleaner, because a raw 400 count is dominated by genuinely malformed client traffic. ## The 429 argument Rate-limit responses are the sharpest case because the answer depends on **why** you shed the request. - Shed because the service was **overloaded** and protecting itself: that user asked for something legitimate and did not get it. It is a bad event. Excluding it means a service can survive any load spike with a perfect availability number simply by rejecting more traffic — an indicator that rewards the failure it is supposed to detect. - Shed because the client **exceeded a documented quota** it agreed to: that is the contract working. Exclude it, or the SLI measures your customers' behaviour instead of your reliability. The implementable version is to distinguish the two at the source: emit different reasons for quota-based and pressure-based shedding, and classify on the reason rather than on the status code. ## Requests with no status code at all Connection resets, timeouts and TLS handshake failures produce no HTTP status. They are real failures and they are invisible to anything counting status codes in the application. This is one more reason the count usually comes from the ingress, which records the aborted connection. ## Multi-status and partial responses An API that returns 200 with a body containing per-item errors, or a GraphQL endpoint that returns 200 with an `errors` array, will report perfect availability while failing. If your API has this shape, the classification must read the body or the service must emit an explicit outcome label alongside the response, otherwise the status code is measuring nothing. ## Write it down, and watch the exclusions The discipline that keeps this honest: **every exclusion is documented, and the excluded volume is graphed.** Two things then become visible — an exclusion that starts growing (a client suddenly producing 30% of traffic as 429s), and the slow accumulation of exemptions that turns an indicator into a number that can only ever read 100%. When the SLI is healthy and the support queue is not, the classification is the first place to look.