What this project is about
Service SLO Lab turns request samples into a reliability decision. It measures availability and p95 latency—the response time at or below which at least 95% of the sample falls—then compares them with service-level objectives, or SLOs. The availability target also becomes an error budget: how many failed requests the measurement window can tolerate.
This is a small Python implementation, not a production monitoring platform. One input file represents the measurement window, and HTTP response codes provide a simplified definition of success. A reviewer can follow each calculation from the original observations to a structured JSON report and a success or failure exit status, without relying on an opaque monitoring dashboard.
How it works
- Request traces
- Availability / p95 latency
- Error-budget analysis
Validate request samples
The loader reads one JSON record per line and converts response status and elapsed response time to numbers. Missing or invalid fields stop the run with a line-specific error; negative latency and empty input are rejected. It does not silently ignore broken rows and report on an unexplained subset.
Calculate the failure budget
HTTP statuses from 200 through 499 count as available; all others count as failures. For N requests, allowed failures equal N × (1 − target), rounded down to a whole number. Subtracting observed failures gives the remaining budget. A negative value means this sample window has exceeded its allowance.
Combine latency and availability
The nearest-rank p95 calculation sorts response times and selects position 0.95 × N rounded up, counting from one; the code's zero-based index is one less. The report includes both targets and separate pass flags. The command succeeds only when both pass, allowing an automated integration or deployment check to use the result.
The important design choices
Use whole-request budgets
Round permitted failures down to a whole request.
The trade-offThe rule is easy to interpret but strict for small windows, which may permit no failures at a high target. Numerical rounding near whole-number boundaries also needs explicit tests.
Evaluate one supplied window
Use a single input file without managing timestamps or a continuously moving time window.
The trade-offThis isolates the arithmetic but does not handle delayed events, retention or alerts about how quickly the budget is being consumed across different time periods.
Explain a failed reliability check
Supply a synthetic request log with an explicit availability target and response-time threshold.
- Validate the input and inspect which response codes count as failures.
- Compare observed failures with the allowed count and inspect the p95 response time.
- Read the separate pass flags to determine whether availability, latency or both missed the target.
What this showsThe JSON report explains the failure exit status rather than leaving an automated workflow with an unexplained red result.
Illustrative example, not an additional measured result.
How it was tested—and what it shows
The checks
The documented example deliberately misses its targets and exits with status 1. The source exposes input checks, target checks and a repeatable percentile calculation; it does not establish any real service's availability or performance. With few requests, one observation can move p95 substantially. A successful HTTP code also does not prove a response was timely, correct or useful.
What to take from the results
The project demonstrates a complete path from request measurements to an actionable pass/fail result. An SLO is a policy choice, not just a chart: what counts as success, how response times are summarized, which requests form the window and how failure budgets are rounded all affect the decision. These definitions must match the user-facing service before supporting operational decisions.
What to keep in mind
- Incomplete or unrepresentative logs lead to incomplete conclusions.
- The tool analyses supplied traces; it is not a production monitoring platform.
Technical notes & source
Built with
Python · request traces · latency · error budgets
Terms used in this project
- SLO
- A target for how reliably a service should work.
- Error budget
- The amount of failure allowed while still meeting that target.