Agent SLOs: define good events before judging the target

Last eight completed requests

An objective needs a precisely defined indicator

This lab separates the good-event definition from the target percentage. Availability regards a completed successful request as good regardless of duration. Successful and fast requires success and a latency no greater than the selected limit. Both use all completed requests in the selected tenant and trailing window as the denominator. A request still in flight has no completion outcome and is excluded. That is an explicit teaching choice; a real timeout-based indicator must include its own accounting for missing or late completions.

Compare two targets against the same service

Restore defaults and inspect second twenty. The one hundred observations in the trailing window all succeeded, so availability is one hundred percent. Change the SLI to successful and fast with the default two-hundred-fifty-millisecond limit, then inspect second twenty again. Only ninety are good, because ten successful requests were slow. The same service now misses a ninety-five-percent target. Raise Latency limit to six hundred milliseconds: every baseline completed request qualifies again. This is a change to the indicator definition, not an operational performance improvement.

Reproduce overspend and recovery without hiding the denominator

With default availability at second thirty, seventy of ninety-eight completed requests are good. A ninety-five-percent target allows 4.9 bad observations against that denominator, but twenty-eight are bad, giving a remainder of minus 23.1. Fractional allowance is mathematical budget, not a fractional request being sent or erased. The current window misses its target. At second fifty-five the incident has left the trailing window; one hundred of one hundred requests succeed and the window meets the target again. Increase Trailing window to sixty to retain the incident history longer. No new monthly error budget is inferred from this short-window recovery.

Do not turn a demonstration into an automatic release approval

The verdict is exact for the selected finite cohort. It is not a statistical confidence estimate or a guarantee about future users. Small denominators make individual failures disproportionately important. A good release decision may also need representative traffic, sufficient observation duration, reliable instrumentation, separate deployment comparisons and explicitly agreed product objectives. The control does not deploy code or approve a release; it shows the consequence of your good-event rule and observation window.

Create a repeatable request cohort

Requests per second sets zero through twenty evenly spaced arrivals during sixty modeled seconds. Baseline error percentage and Incident error percentage feed an integer remainder accumulator; each time it reaches one hundred, that request fails and the remainder is reduced by one hundred. Incident start and Incident duration choose which arrival seconds use incident behavior. Base latency is increased by a deterministic zero-to-forty-millisecond request-index variation. Slow extra latency is added to ten percent of baseline arrivals and sixty percent of incident arrivals using another remainder accumulator. These schedules can correlate with alternating alpha/beta tenant assignment; they are a repeatable teaching workload, not independent random production observations.

Choose the aggregation and good-event rule

Tenant filter selects all, alpha or beta without regenerating the underlying request records. Trailing window sets one through sixty seconds. At inspection time t, it includes matching completed requests strictly after max of zero and t minus window, through t inclusive. Availability counts successful completed requests as good. Successful and fast additionally requires duration at or below Latency limit; a failed fast request is still bad. Target sets eighty through 99.99 percent in hundredths of a percentage point. The comparison uses integer good-count arithmetic against the configured target, not the rounded percentage printed on a card.

Inspect progression and the evidence

Play advances through sixty seconds; Pause freezes the selected snapshot. Next second advances one integer second, Restart rewinds, Show final result selects sixty, Speed changes viewing pace and Inspect time scrubs. Each input change rebuilds the cohort or aggregation and pauses at zero; Restore defaults resets every setting. The line shows the selected trailing-window SLI against the target. Bucket bars show counts at or below each latency bound, so they are cumulative, not disjoint bars to add together. The last eight completed requests table exposes start, completion, latency, tenant and result. Exact evidence includes all selected sample IDs and every aggregate denominator.

Keep the missing-data and model limits explicit

At zero traffic or before a matching completion, there is no measured success fraction, percentile or objective verdict. Unknown is not healthy. Cumulative counters only cover observed completions since time zero and never reset during a run. No counter-reset detection, exporter loss, scrape cadence, clock skew, timeout censoring, histogram interpolation or Prometheus server is implemented. Percentile p95 is nearest-rank over the full raw window sample, not estimated from bucket bounds. The fixed arrival and response schedule has no queue, shared capacity, retries or feedback. Some final arrivals complete after sixty seconds and remain in flight at the horizon. This is not evidence that a real agent meets an SLO.