Service Level Indicators

A Service Level Indicator (SLI) is a defined measurement of service behavior that reflects an important user or business requirement. For an online store, useful indicators might include the proportion of checkout attempts completed successfully and the proportion completed within two seconds. For a reporting pipeline, the relevant indicator might be the percentage of reports available before a business deadline. These measurements connect architecture decisions to outcomes rather than merely showing that infrastructure is running.

Distinguish an SLI from a Service Level Objective (SLO) and a Service Level Agreement (SLA). The SLI is the measurement, such as the percentage of eligible requests that succeed. The SLO specifies a target and evaluation window, such as at least 99.9% success over a rolling 30-day period. An SLA is an agreement that can include service commitments, measurement rules, exclusions, and remedies. Measuring an SLI does not itself establish a contractual guarantee.

Define each indicator precisely. A request-based availability SLI is commonly calculated as successful eligible requests divided by total eligible requests, multiplied by 100. Specify which requests qualify, what constitutes success, where measurement occurs, and how timeouts, retries, client errors, and missing telemetry are handled. A successful HTTP response may still represent a failed business operation, so an order-placement indicator may need application-level confirmation rather than status codes alone. Account for failures that occur before traffic reaches the application, including DNS or connection failures.

Latency indicators should reflect the distribution of user experience rather than only an average. A 99th-percentile response time exposes slow responses that an average can hide. Alternatively, measure the fraction of eligible requests completed below a business-defined threshold. For asynchronous workloads, completion delay and data freshness are often more meaningful than API response time. Define separate indicators for critical journeys when a high-volume, low-value endpoint could otherwise hide failures in an important operation.

In cloud environments, combine application metrics, load balancer telemetry, logs, distributed traces, and synthetic transactions. Application instrumentation can confirm business success; external probes can identify reachability problems even when request volume is low. Infrastructure measurements such as CPU utilization, healthy target count, and database connections help diagnose problems and anticipate capacity limits, but they are not usually direct evidence that users can complete their work.

Use these indicators to evaluate high-availability designs. If checkout must remain usable during an Availability Zone failure, deploy the necessary application and data components across zones and test whether checkout success and latency remain within their objectives during failover. A healthy virtual machine or successful load balancer health check does not prove that authentication, payment processing, or database writes work. Dependency failures and insufficient remaining capacity can still violate the business requirement.

Measurement involves trade-offs. Detailed instrumentation increases cost and cardinality, while sampling can miss rare failures. Global aggregation can conceal regional outages, but excessive segmentation can create noisy, low-volume indicators. Request-based availability weights busy periods more heavily than quiet periods; time-based availability answers a different question. Do not translate a request-success target directly into a permitted downtime duration. Use clearly defined windows, investigate missing data, and alert on sustained or rapid consumption of the SLO error budget rather than every isolated failure. An error budget represents the amount of unsuccessful service behavior the objective permits, not permission to ignore critical incidents.