SLO/SLI Metrics Template
Once a site goes live, the hardest management problem is often "we can't say clearly whether things are good or not": is the occasional slowness a coincidence or a trend? What is a reasonable stability target? SLO and SLI turn that vague feeling into measurable numbers. An SLO (Service Level Objective) is the service goal you commit to; an SLI (Service Level Indicator) is the value you actually measure. Compare the two and stability becomes obvious. Instead of reporting "the page feels slower", you can show hard data like "P95 went from 700ms to 950ms, above the 800ms target".
The most counterintuitive part of the SLO framework is that it encourages you to "deliberately leave room for failure" rather than chase 100% stability. The reason is practical: a 100% target means zero tolerance, and the team drowns in endless alerts, exhausted from defending an unrealistic number with no energy left for the optimizations that actually matter. The value of an SLO is that it makes explicit "how bad can we accept", and within that range you can sensibly balance release speed against stability.
Core Metric Recommendations
| Metric | Suggested SLO | Note |
|---|---|---|
| Availability | 99.9% | About 43 minutes of downtime allowed per month |
| Time to First Byte | P95 < 800ms | 95% of requests return within 800ms |
| Critical API success rate | > 99.5% | Core endpoint error rate under 0.5% |
| Alert-to-response time | < 10 minutes | How quickly a failure is picked up |
These numbers are not guesses: 99.9% availability corresponds to about 8.8 hours per year and 43 minutes per month of downtime. Before setting targets, ask "what is the lowest level users can tolerate" rather than "what can the technology achieve". Choosing the metrics matters too: an SLI should measure something users can actually feel. For a website, availability and time-to-first-byte (TTFB) matter more than server CPU usage, because users do not feel CPU — they only feel "does it open fast". Do not over-collect; maintaining 3-5 core SLIs is enough, and any more means nobody actually watches them.
Using the Error Budget
The gap between the SLO and the actual SLI is the error budget. If the monthly availability target is 99.9% and you actually run at 99.99%, the extra 0.09% is your budget. While budget remains, release new features with confidence; once it is spent, hold back changes and prioritize stability. This turns "should we ship?" from a battle of feelings into a battle of numbers.
Here is a real scenario. A team's monthly availability SLO is 99.9% (a 43-minute budget). Mid-month, a database migration triggers a 25-minute outage, burning more than half the budget. The right move is to freeze non-urgent feature releases, prioritize chasing the migration's leftover issues, and keep the remaining 18 minutes for everyday surprises. If budget remains at month's end, resume the normal release cadence. This "decide whether to ship by budget" mechanism is far more convincing than any "don't release this week" gut call.
Weekly Report Template
| Metric | This Week | Target | Deviation | Cause and Action |
|---|---|---|---|---|
| Availability | 99.95% | 99.9% | +0.05% | none |
| TTFB P95 | 720ms | 800ms | +80ms | cache hit rate up 5% |
| API success rate | 99.2% | 99.5% | -0.3% | payment callback timeout; retry added |
Produce this table every week and tie each deviation to a concrete action instead of writing "fluctuation". After a few weeks you can see whether stability is improving or degrading.
Implementation Advice
An SLO is not finished once it is written into a doc. Connect SLI collection to your monitoring stack and record it continuously with a tool like Prometheus — rule design is covered in Prometheus alert rule design. Teams without a full monitoring stack can start with synthetic monitoring — see synthetic monitoring practice. Error budget mechanics are detailed in SLO error budget practice.
A practical upgrade is burn-rate alerting: rather than waiting until the monthly budget is exhausted, alert the moment the budget is being consumed abnormally fast. For example, trigger an urgent alert when more than 2% of the budget is burned within an hour (meaning the monthly budget would run out early at this pace). This moves the discovery from "end of month" to "the first hour of the incident". Example configuration:
# Error rate above 10% over a 5-minute window
sum(rate(http_requests_total{job="api",status=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="api"}[5m]))
> 0.10
This PromQL measures the API's 5xx error rate and alerts above 10%. Tune the number to your SLO: with a 0.1% error budget (99.9% target), burning 2% of the budget in an hour corresponds to roughly a 0.002% error-rate threshold — the exact formula is in the error budget documentation above.
Frequently Asked Questions
- Is 99.99% always better? Higher targets mean more pressure and cost; if users and the business accept 99.9%, there is no need to push harder.
- How do I count SLIs accurately? Keep the collection source consistent — pick the load balancer or application logs as the source of truth and stick with it.
- Can I do SLOs without a monitoring system? Yes — start by accumulating data with manual checks and synthetic monitoring, run for a month or two, then set targets. That beats pulling a number out of thin air.
- What if the error budget is exhausted? Freeze non-urgent changes, prioritize fixing known issues, and if needed publish a transparency notice to users — do not quietly lower the SLO.
References
Reference: Google SRE Book (SLO chapter) https://sre.google/sre-book/service-level-objectives/
Reference: Google Cloud SLO documentation https://cloud.google.com/stackdriver/docs/solutions/slo
Reference: Google SRE on implementing SLOs https://sre.google/sre-book/implementing-slos/