Set Reliability Targets Your Business Actually Needs

Detailed practical guide

Prepare your workspace and inputs

Use a fixed ten-request interval with one failed request. Save the script as slo_check.py and run python3 slo_check.py. The 99 percent target below is a learning example and must be agreed separately for a real service.

Platform context: Python 3.10+; local CSV parsing. No monitoring backend is required for the arithmetic test.

Scenario to reproduce or investigate

A dashboard shows a green server while users receive failed responses. Define a good request as an eligible application request with status below 500 and compare the observed result with a written objective.

1. Fix the denominator before calculating a percentage

   For this lab every row is eligible, and 2xx, 3xx and 4xx responses count as non-server-errors. This deliberate definition is not universal: if denied or missing-resource responses represent failed user work, change the indicator. Keep internal health checks out of the denominator in your real query.

   Command, configuration or input

   Window: fixed lab fixture
   Eligible requests: all 10 rows
   Good request: 200 <= status < 500
   Learning target: 99%

   Expected result · ผลที่ควรเห็น

   Another operator can reproduce which rows are included and why each is good or bad.

   If it fails · เมื่อไม่ผ่าน

   If the business regards a 404 or 429 as an unsuccessful operation, define that before measuring rather than changing it after a bad result.

2. Calculate and assert the SLI and budget

   The script uses Decimal so the target and observed ratios are explicit. A negative remaining budget means the interval has already exceeded its allowed bad-event count; it does not change the measured traffic.

   Save and run this example

   import csv
   from decimal import Decimal
   from io import StringIO
   
   data = "request_id,status\n" + "".join(f"r{i},{500 if i == 10 else 200}\n" for i in range(1, 11))
   rows = list(csv.DictReader(StringIO(data)))
   total = len(rows)
   assert total > 0
   good = sum(200 <= int(row["status"]) < 500 for row in rows)
   bad = total - good
   target = Decimal("0.99")
   observed = Decimal(good) / Decimal(total)
   allowed_bad = Decimal(total) * (1 - target)
   remaining = allowed_bad - Decimal(bad)
   assert good == 9 and bad == 1
   assert observed == Decimal("0.9")
   assert remaining == Decimal("-0.90")
   print("Observed success: 90.0%; target: 99.0%")
   print("Bad events: 1; allowed: 0.10; remaining budget: -0.90")
   

   Expected result · ผลที่ควรเห็น

   The observed success is 90.0 percent, the allowed bad-event count is 0.10 and the remaining budget is -0.90.

   If it fails · เมื่อไม่ผ่าน

   If the denominator is zero, return no data rather than 100 percent. If request IDs are duplicated, decide whether the input is an event log or a deduplicated request table before counting.

3. Implement the same indicator in the actual dashboard

   Export a representative bounded interval from your monitoring system and map its status and request identifiers to the same definitions. Compare backend totals with the export and explain exclusions. Have the service owner agree the target, window and action when the budget is depleted; do not turn the ten-request arithmetic example into an alert threshold.

   Command, configuration or input

   Eligible count → good count → good/eligible → objective comparison → recorded response decision

   Expected result · ผลที่ควรเห็น

   Dashboard and exported calculation reconcile for the same interval, and missing data remains distinguishable from perfect service.

   If it fails · เมื่อไม่ผ่าน

   If totals differ, compare timezone, retries, synthetic probes and sampling before tuning the SLO or notification rule.

Recovery and cleanup

The local calculation changes no service. Save the previous dashboard query before replacing it and restore that query if the new definition loses eligible traffic or misclassifies requests.

Apply to actual work and known limits

Replace the fixture with a sanitized export. Use your agreed production window, deduplication policy and measurement source; this calculation does not demonstrate the reliability of the source collector.

The included self-contained Python fixture was executed successfully in this Linux environment. External products and production infrastructure were not exercised.

Observed success: 90.0%; target: 99.0%
Bad events: 1; allowed: 0.10; remaining budget: -0.90