Service-level indicator

As explained in Cloud Observability in Action

A service level indicator is a quantitative measurement of a service aspect relevant to evaluating a service level objective.

A service-level indicator (SLI) is a quantitative measurement of how a service is experienced by its customer. Every SLI is a metric, but only service-relevant metrics qualify as SLIs. Common SLIs measure availability, error rate, latency, successful or failed jobs, and throughput. section 10.1.2

Choose the measurement according to the service being evaluated:

• Measure uptime, availability, reachability, error rate, or response duration for synchronous services. section 10.1.2
• Measure successfully completed or failed jobs for asynchronous services such as batch workloads. section 10.1.1 section 10.1.2
• Measure throughput when the relevant customer experience concerns sustained transaction capacity. section 10.1.2

SLIs provide the measurements used to assess service-level objectives (SLOs), while SLOs express goals for the service team and service-level agreements (SLAs) communicate contractual commitments to customers. Teams can aggregate SLI values, calculate percentiles, establish dashboards and alerts, and report whether an SLO was met. Thresholds require judgment: stricter reliability goals demand more effort, and a dependent service can limit the reliability of the overall request path. section 10.1 section 10.1.3 section 10.4

Chat2Much API availability

For the Chat2Much API, product and engineering establish SLIs for availability, request count, and errors to track a monthly availability SLO. A load test observes 1,000,000 requests and 6,942 failures; allowing headroom by rounding failures to 7,000 supports a realistic 99% availability commitment. Production dashboards and alerts then track the SLIs and report performance against the SLO. section 10.2.1

Figure 10.1 Interaction and dependencies between SLAs, SLOs, and SLIs

Use the relationship diagram to distinguish measurements from organizational goals and contractual commitments. section 10.1

How Cloud Observability in Action covers it

How deep it goes

Explains definitions, service-specific measures, organizational relationships, trade-offs, and a worked availability calculation, while deferring deeper SLO terminology.

Examples

Uses availability, request errors, latency, completed jobs, throughput, and the Chat2Much API availability calculation.

What it assumes

Assumes basic service metrics and customer perspectives, while defining SLIs alongside SLOs and SLAs from foundational terminology.

What you can do after

Operate/configure dashboards, alerts, and Prometheus-ecosystem tooling to track SLIs against established SLOs.

How it connects

Connects metrics with observability, service-level objectives, service-level agreements, availability, error rate, latency, and throughput.

liveBookmanning.com

Read Cloud Observability in Action on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Effective Platform EngineeringA service-level indicator is a quantitative measurement of a service’s reliability or performance from the perspective of its users.
• 

  liveBookmanning.com
  Automating API DeliveryA service level indicator is a quantitative measure of an aspect of a service's health or performance.

Compare how 3 books explain service-level indicator →

Related concepts

• service-level objectiveconfigured by · A service-level objective is a target value or range for a measurable service-level indicator over a specified period.
• performancekind of · Performance is the measurable effectiveness or operational behavior of a system under specified conditions, assessed through relevant qualities such as task results, speed, responsiveness, throughput, or resource use.
• metrickind of · A metric is a quantitative measure used to characterize or assess a property, condition, behavior, performance, or outcome.
• contractmeasures · An API contract is a specification of the operations, data, and behavioral expectations that govern interactions between software components.
• meanmeasures · A mean is a measure of central tendency, calculated as the arithmetic average of values or, for a random variable, as the probability-weighted average of its possible values.
• uptimemeasures · Uptime is the duration or proportion of a specified period during which a system or service is operational and available to provide its intended function.

This explainer was generated by Manning's knowledge graph from the text of Cloud Observability in Action. The section links point to the parts of the book it draws on.