An SLI is conventionally specified as the ratio of good events to valid events. Why is defining "valid" as consequential as defining "good", and what do teams commonly get wrong in that denominator?

## The ratio and its two halves The standard shape of an SLI is ``` SLI = good events / valid events ``` Most discussion goes into "good" — which status codes count, which latency threshold. The denominator gets less attention and decides more, because it defines the population the service is being judged on. Two services with identical behaviour and different denominators report different reliability. ## The dilution trap The most common defect is a denominator that includes traffic which is trivially successful. Health checks fire every few seconds from every load balancer and every orchestrator, synthetic probes run on a schedule, and uptime checkers hit a cheap endpoint that touches nothing. All of them succeed almost always, and all of them are cheap enough to run at a rate far above real user traffic. Suppose probes generate ten times the request volume of users. If every real user request fails for an hour, the measured success rate over that hour is about 91% rather than 0% — the service looks degraded rather than down. Over a 28-day window that outage may not even breach the target. The fix is to filter the denominator to requests that represent real usage, and to keep probe results as their own separate signal rather than mixed into the user-facing indicator. Crawler and scanner traffic causes a subtler version of the same problem, and can distort in either direction: bots that hammer a cached endpoint dilute the denominator with easy wins, while a scanner probing nonexistent paths can generate a wall of errors that has nothing to do with user experience. ## The exclusion trap The opposite mistake is excluding too much. Client errors are the usual argument: a 400 or a 404 is the caller's fault, so it should not count against the service. Often true — and it creates a blind spot the moment a deployment starts rejecting valid requests as malformed. A change that turns 2% of real traffic into 400s is a serious regression that an indicator excluding all 4xx will never see. Workable positions on this exist and should be chosen deliberately rather than by default: - Exclude 4xx from the numerator's fault but keep a separate indicator or alert on client-error *rate*, so a sudden rise is still visible. - Treat specific codes differently — 429 (rate-limited by you) and 401/403 arguably reflect your behaviour, while 404 for a genuinely absent resource does not. The same reasoning applies to declared maintenance windows, requests from internal test accounts, and traffic from a customer running a load test against production. Each exclusion may be individually reasonable; the pattern to watch is that every one of them makes the number better. ## Governance: the denominator is a lever Because exclusions only ever improve the ratio, the definition of "valid" is where pressure lands when a target is being missed. "Should we really be counting those requests?" is a question that always has a plausible answer. The defence is procedural rather than technical: write the definition down alongside the target, require the same review to change it as to change the threshold, apply changes going forward rather than retroactively, and record when each change took effect so historical comparisons stay honest. ## Request-based versus time-window indicators Not everything can be expressed as a count of requests. A second common form is the time-window ratio: ``` SLI = good time slices / valid time slices ``` A minute is "good" if some condition held throughout it — success rate above a bar, a pipeline's data fresher than a threshold, a queue below a depth. This suits things with no natural per-request event: batch pipelines, data freshness, background workers. Its trade-off is important and often missed. A time-window indicator weights every bad minute equally: a minute in which one request out of a million failed and a minute in which everything failed both count as one bad minute. That makes low-traffic incidents look as severe as total outages and vice versa. Request-based indicators weight by volume, which usually tracks user impact better — but they need enough events to be meaningful, which is exactly what low-traffic services lack. Choose the form to match what the service actually produces, and say which one you chose when quoting a number, because the two are not comparable.