SLIs and SLOs for teams without an SRE
SRE hiring is not a prerequisite for reliability engineering. Three SLIs chosen honestly — availability, latency, correctness — with SLO targets and error budgets give small teams what a wall of dashboards cannot: a shared definition of "broken."
The Grafana wall has forty-seven panels. During the incident, nobody knew which one mattered. Error rate was elevated on a non-critical endpoint. p99 latency on checkout was fine. A background job was red. On-call rotated through panels for twenty minutes before someone asked the question that should have been answered before the alert fired: what does broken look like for this product? SLIs and SLOs without an SRE team are not headcount — they are three numbers the whole engineering org agrees measure user-visible reliability, plus targets that turn metrics into decisions.
Site Reliability Engineering popularized the vocabulary. The practices do not require SRE job titles. A five-person startup with production customers needs SLOs more than a fifty-person team with an observability platform nobody configured. SLOs are product decisions expressed as math: how reliable must checkout be, how fast must search feel, how often can data be wrong before users leave.
SLI, SLO, and error budget in plain terms
| Term | Definition | Example |
|---|---|---|
| SLI (Service Level Indicator) | A measurable proxy for user experience | Successful checkout requests / total checkout requests |
| SLO (Service Level Objective) | Target range for an SLI over a window | 99.9% checkout success per 30-day rolling window |
| Error budget | Allowed unreliability below 100% | 0.1% = ~43 minutes downtime/month at 99.9% |
| SLA (Service Level Agreement) | Contractual commitment with consequences | Usually stricter SLO + legal terms — not required for internal SLOs |
SLIs must be measurable, user-centric, and honest — not "CPU under 80%" but "requests completing successfully under 500 ms."
SLOs must be achievable and owned — a number nobody can hit trains everyone to ignore SLOs.
Error budgets connect reliability to product velocity: budget remaining → ship features aggressively. Budget exhausted → freeze risky deploys, focus on stability. Without error budgets, SLOs are posters.
A dashboard without an SLO is a Rorschach test during incidents.
Three SLIs most teams should start with
Do not start with fifteen SLIs. Start with three that map to user pain.
1. Availability / success rate
SLI = (successful requests) / (total valid requests)
Define "successful" per endpoint — HTTP 2xx/3xx for APIs, job completion for async. Exclude client errors (4xx) unless they indicate server misconfiguration.
SLO starting point: 99.9% for core API, 99.5% for non-critical paths. Adjust based on actual performance — setting 99.99% when current is 99.5% produces permanent budget exhaustion.
2. Latency
SLI = proportion of requests completing under threshold T
Use percentiles aligned to user experience — p95 or p99, not average. Average hides tail latency that drives churn.
Example SLO: 95% of search requests complete under 300 ms per 30 days.
Measure at the load balancer or edge — not only inside the service — to include network and gateway overhead.
3. Correctness / freshness (when applicable)
Harder to measure universally. Examples:
- Data pipeline: % of hourly aggregates published within 15 minutes of hour close
- Payment: reconciliation mismatch rate below 0.01%
- Search index: % of queries returning results from index updated within 60 seconds
Skip correctness SLI if no clear user-visible data contract exists yet. Do not invent one to fill a template.
Implementing SLOs without an observability platform team
Minimum viable SLO stack:
Metrics source. Existing APM, Prometheus, cloud provider metrics, or structured logs aggregated to time series. Perfection is not required — consistent measurement is.
SLI recording rules. Prometheus recording_rules, Datadog monitors, or weekly SQL against log warehouse — compute SLI ratio over rolling window.
Burn rate alerts. Alert when error budget consumption accelerates — not when SLO is already broken for the month.
| Alert type | When it fires | Purpose |
|---|---|---|
| Fast burn | 2% of monthly budget consumed in 1 hour | Page on-call — active incident |
| Slow burn | 10% of monthly budget consumed in 6 hours | Ticket — investigate trend |
| Budget exhausted | 100% consumed | Freeze risky releases |
Single status page. One URL or doc: current SLO status per SLI, budget remaining, last incident impact. Updated automatically if possible.
Feature flags as release infrastructure integrate with error budgets — when checkout SLO budget is low, flags disable non-critical paths before the next deploy risks another burn.
SLO review cadence replaces dashboard tourism
Weekly or biweekly 30-minute SLO review:
- Budget remaining per SLI
- Incidents that consumed budget — root cause, fix shipped?
- Deploy correlation — did releases precede burns?
- SLO target adjustment proposals — only with data
Monthly: are these still the right three SLIs? Product changes shift what users feel. SLOs that measured last year's product may not measure this year's.
SLO targets are not permanent. Tighten when reliability improves and users expect more. Loosen when targets were fantasy — but looser targets must be explicit product decisions, not silent surrender.
How should small teams choose and enforce SLOs?
These questions prevent SLO programs that die after one spreadsheet.
How many SLIs are enough?
Three to five for the whole product initially. One primary SLI per critical user journey — checkout, auth, core read path. More SLIs dilute attention; fewer miss real pain.
What error budget policy should non-SRE teams adopt?
Simple rule: budget below 25% remaining → no discretionary risky deploys without explicit ack. Budget exhausted → stability sprint until budget recovers. Write the policy before the first exhaustion — not during the argument.
Do SLOs replace on-call runbooks?
No. SLOs tell you that you are broken and how much budget remains. Runbooks tell you what to do. Pair SLO burn alerts with rollback strategy decision trees — alerts without actions waste pages.
A common argument runs the other way
The opposing view holds that SLOs are enterprise overhead — that small teams should move fast and fix incidents when they happen instead of measuring reliability mathematically.
Small teams feel incidents more acutely because nobody else absorbs the pain. SLOs do not slow velocity — error budgets authorize velocity when reliability allows. Without them, every deploy argument is subjective ("feels risky") and every incident retrospective reinvents what "broken" means.
The overhead of three SLIs is one afternoon of definition and a recurring thirty-minute review. The overhead of forty-seven Grafana panels during a confused incident is measured in customer trust.
Key takeaways
- SLIs measure user-visible reliability; SLOs set targets; error budgets connect reliability to release decisions.
- Start with three SLIs: availability, latency, and correctness/freshness where applicable.
- Burn rate alerts fire before monthly budget is exhausted — fast burn pages, slow burn tickets.
- SLO targets must be achievable — fantasy targets train teams to ignore SLOs.
- Error budget policy gates risky deploys when budget is low — write policy before first exhaustion.
- Review SLOs biweekly; adjust targets and SLI selection as product evolves.
Conclusion
An SRE team is a staffing model, not a reliability prerequisite. SLIs and SLOs are how teams agree what broken means before the pager fires — three honest indicators, targets grounded in current performance, and error budgets that make reliability a input to shipping decisions instead of a post-incident regret.
The afternoon exercise: pick the one user journey whose failure would end the week badly. Define its SLI. Set an SLO from last month's data. Configure one burn rate alert. Everything else is iteration.