# A successful stream for an SLO: define the event and denominator

Define a successful inference stream for SLOs across accepted, rejected, completed, failed and cancelled work, partial answers and explicit good-event denominators.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/provider-stream-success-sli-denominator/
Language: en

A service can return HTTP 200 and later fail inside its stream. A status-only SLO counts success although the user lacks a complete result. Conversely, a client may cancel intentionally, which should not automatically become provider failure without policy. Reliable SLIs begin with observed-event and denominator definitions rather than a desired dashboard percentage.

## Define the operation boundary

[Google SRE's SLO guidance](https://sre.google/workbook/implementing-slos/) connects indicators to useful user outcomes. For streaming, decide whether one operation means an accepted request, completed attempt or logical request containing retries. These units produce different denominators and must not change silently between reports.

Record the accounting start and service scope. A pre-generation rejection may matter for availability despite never reaching the engine queue. Excluding it requires an explicit definition rather than a preference for a better-looking result.

## Separate terminal outcomes

Completed, failed, cancelled and incomplete are useful classifications, separate from admission states accepted and rejected. Final outcomes should be mutually exclusive within the chosen record. A result counter increments once, while state transitions remain diagnostic events.

[Prometheus instrumentation guidance](https://prometheus.io/docs/practices/instrumentation/) emphasizes consistent operation, error and latency accounting. Starts and completions differ over short windows. The denominator must match the measurement method, or an arrival spike can look like a quality change without evidence.

## Validate stream completeness

The [OpenRouter streaming documentation](https://openrouter.ai/docs/api_reference/streaming) shows failures after response commitment arriving inside SSE without changing an already sent HTTP status. Status-only validation is insufficient. Check application outcome, framing and required endpoint-specific final data.

Do not require one terminal marker for every API. Chat Completions differs from other interfaces. Retain endpoint and validator version in SLI records so migration cannot make new events either universally unknown or automatically successful through an overly broad parser fallback.

## Define cancellation policy

Distinguish client cancellation, server-deadline expiry and forced instance shutdown. Connections can close in all three cases, but responsibility and usefulness differ. If cause cannot be established, retain an unknown outcome instead of assuming client intent.

Partial text can help an application without automatically making the operation complete. Product policy determines whether it qualifies as good. Store the rule and examples beside the metric so engineers and product owners interpret it consistently.

## Test the denominator with fixtures

Create a small set covering complete success, admission rejection, pre-header failure, midstream failure, cancellation and truncation without a terminal result. Define outcome and denominator membership for each, then compare exported counters against a manually prepared table.

Related guides cover [stream errors](/journal/openrouter-stream-errors/) and [operation reporting](/journal/capacity-reporting/). The result is a testable SLI definition rather than a specific SLA promise. Without semantics, even accurate good/total arithmetic may measure convenient internal activity instead of user value. Keep the inclusion table versioned so a later policy change is visible as a definition change rather than misreported as a reliability improvement.