SLI
What did the service deliver?A Service Level Indicator is a measured ratio, distribution, duration, or count that represents a user-visible aspect of service behavior.
SLI detailsOverviews
SLI, SLO & SLA
Reliable services need a shared language that connects measurements, engineering targets, customer commitments, and delivery decisions. SLIs describe what happened, SLOs define how good the service should be, and SLAs formalize external commitments.
The core model
Measurement, target, commitment
The three terms are related, but they answer different questions and belong to different decision layers.
SLO
How good should it be?A Service Level Objective is a target for an SLI over a defined window, such as 99.9% successful requests during a rolling 30-day period.
SLO detailsSLA
What have we promised externally?A Service Level Agreement is a contractual or commercial commitment that may define remedies, exclusions, support obligations, and measurement rules.
SLA detailsService Level Indicator
Design an indicator around user-visible good events
An SLI is useful only when its population, success criteria, measurement source, aggregation, exclusions, and time window are explicit.
Event population
Which requests, jobs, users, tenants, regions, or operations are included? Invalid requests and planned exclusions should be defined rather than silently removed.
Good-event criteria
What makes an event good? Examples include a successful status, a correct result, completion below 300 ms, or processing before a freshness deadline.
Measurement point
Measure as close to the user experience as practical: load balancer, synthetic probe, client telemetry, business event, or validated application result.
Aggregation
Choose ratios and distributions carefully. Prefer request-based availability and percentile latency over host uptime and simple averages.
Availability SLI
good requests ÷ valid requestsLatency SLI
requests below threshold ÷ valid requestsFreshness SLI
records updated before deadline ÷ eligible recordsCorrectness SLI
correct outcomes ÷ completed outcomesService Level Objective
Turn “reliable enough” into a measurable engineering target
An SLO combines an SLI, target, measurement window, and policy. It should reflect user tolerance and business priorities—not an arbitrary number of nines.
A complete SLO states
- The exact SLI definition
- The target threshold or percentile
- The rolling or calendar measurement window
- Scope by endpoint, region, tenant, or workload class
- Exclusions and data-quality rules
- The response when the objective is at risk
Error budget
The error budget is the permitted unreliability implied by the SLO. A 99.9% availability objective allows 0.1% bad events during the window.
- Objective
- 99.9% good events
- Error budget
- 0.1% bad events
- Decision use
- Balance feature delivery, risk, and reliability work
Service Level Agreement
Translate service expectations into an external commitment
An SLA is broader than a reliability target. It can define service scope, measurement methods, support response times, exclusions, credits, remedies, and responsibilities.
Service scope
Which product, plan, region, endpoint, or customer workload is covered?
Measurement and reporting
Whose telemetry is authoritative, how downtime is calculated, and when reports are issued?
Exclusions
Planned maintenance, customer-caused failures, force majeure, unsupported configurations, or third-party failures may be treated separately.
Remedies
Service credits, escalation, termination rights, or other contractual outcomes when the commitment is missed.
Metric categories
Choose indicators that represent the service from several angles
The strongest SLI portfolio connects user experience, processing quality, workload, resource limits, and business outcomes.
| Category | Example SLIs | What they measure | Related concepts |
|---|---|---|---|
| Availability | Uptime %, success rate, good-event ratio | Is the service reachable and usable when needed? | |
| Latency | P50, P95, P99 response or processing time | How quickly do users or downstream systems receive a result? | |
| Reliability | Error rate, timeout rate, failed jobs, retry exhaustion | Does the operation complete correctly and consistently? | |
| Throughput | RPS, QPS, TPS, messages/s, records/min | How much useful work is the system completing? | |
| Quality and freshness | Cache hit rate, queue lag, replication lag, stale-result rate | Is the result sufficiently fresh, complete, and useful? | |
| Saturation | CPU, memory pressure, connection-pool use, disk I/O, queue depth | How close is the system to a resource or dependency limit? | |
| Business outcome | Payments completed, invoices processed, successful synchronizations | Is the service producing the user or business outcome that matters? |
Illustrative production targets
Realistic SLI and SLO pairs
These are common starting ranges, not universal standards. Targets should be derived from user needs, system economics, dependency limits, and the cost of achieving additional reliability.
| SLI | Typical SLO | Example definition |
|---|---|---|
| API availability | ≥ 99.9% | Successful valid requests ÷ all valid requests over 30 days |
| P95 API latency | < 200–300 ms | At least 95% of valid requests complete below the threshold |
| P99 API latency | < 500 ms | At least 99% of valid requests complete below the threshold |
| Error rate | < 0.1–1% | Failed valid operations ÷ all valid operations |
| Queue processing delay | < 1 minute | Age of the oldest eligible message or event-to-completion delay |
| Database replication lag | < 5 seconds | Difference between primary commit position and replica application |
| Successful deployments | > 99% | Deployments completed without rollback or service-impacting failure |
| Backup success rate | 100% | Scheduled backups completed, verified, and retained as required |
The complete measurement landscape
Connect demand, service behavior, resources, and outcomes
Operational understanding comes from combining leading indicators, user-facing SLIs, diagnostic infrastructure signals, and business results.
Traffic
- RPS and QPS
- Active and concurrent users
- Transactions or jobs per second
- Queue depth and arrival rate
- Payload size and traffic mix
Traffic metrics describe demand. They explain what work arrived, but not whether the service handled it well.
Reliability
- Availability and success rate
- Error and timeout rate
- Failed or dead-lettered jobs
- Retry exhaustion
- Incident and recovery time
Reliability metrics describe whether useful work completed correctly and continuously.
Performance
- P50, P95, and P99 latency
- Database query time
- Queue wait and processing time
- Cache hit rate
- Dependency response time
Performance metrics should use distributions and critical-path segmentation rather than averages alone.
Infrastructure
- CPU and throttling
- Memory use and pressure
- Network throughput and errors
- Disk I/O and saturation
- Connection-pool utilization
Infrastructure metrics diagnose causes and capacity risks; they are rarely good user-facing SLIs by themselves.
Business
- Invoices processed
- Payments completed
- Orders fulfilled
- Successful synchronizations
- Records delivered within freshness targets
Business metrics can be the strongest SLIs when the service exists to deliver a concrete outcome.
Traffic and demand→Application and dependencies→User-visible SLI→Business outcome
Operating with objectives
Use SLOs to drive alerts, prioritization, and delivery policy
Alert on user impact
Prefer alerts tied to rapid error-budget consumption or sustained SLI degradation rather than every infrastructure anomaly.
Segment before aggregating
Break down by critical endpoint, region, tenant class, dependency, and workload type. A global average can hide a severely affected segment.
Review the objective
If an SLO is always met with enormous margin, it may not guide decisions. If it is chronically missed, either the service or the objective needs deliberate change.
Connect to delivery
Use budget policy to decide when to accelerate changes, add safeguards, pause risky releases, or prioritize reliability engineering.