Service Level Indicator (SLI)

An effective SLI is expressed as a numerical value derived from a direct measurement of the system. It avoids subjective terms like "fast" or "good" in favor of precise metrics.

• Examples: p99 latency < 200ms, error rate < 0.1%, data freshness < 5 minutes.
• Anti-pattern: "The dashboard should load quickly."
• Corrected SLI: "The 95th percentile dashboard query latency should be under 2 seconds."

The SLI must measure an aspect of the service that directly impacts the end-user experience or the validity of downstream business decisions. It answers the question: "What does the user care about?"

• For an API: Request latency and success rate.
• For a batch data pipeline: Data freshness (when was it last updated?) and data completeness (are all expected records present?).
• An internal metric like "CPU utilization" is a useful diagnostic tool but is not a user-facing SLI.

The definition and calculation of the SLI should be easily understood by engineers, product managers, and business stakeholders. Complexity obscures ownership and hinders effective action.

• Good: "Percentage of successful HTTP requests (status code < 500)."
• Overly Complex: "A weighted harmonic mean of successful requests, excluding those from internal health checks, adjusted for regional load-balancer variance."
• Simplicity ensures the entire team can reason about what the metric means and what actions improve it.

The engineering team responsible for the service must have direct influence over the factors that affect the SLI. If the team cannot improve the metric through code changes, infrastructure tuning, or process improvements, it fails as a useful indicator.

• Actionable: Pipeline runtime SLI can be improved by optimizing query logic or scaling compute resources.
• Not Controllable: An SLI based on the uptime of a third-party SaaS provider outside your team's control. This should be covered by a provider's SLA, not your internal SLO.

Effective SLIs are not chosen in a technical vacuum. They must be explicitly linked to business outcomes and prioritized accordingly. This alignment justifies investment in reliability work.

• An e-commerce checkout service requires an ultra-high availability SLI (e.g., 99.99%) because downtime directly loses revenue.
• An internal analytics batch pipeline might have a stricter freshness SLO (data must be ready by 9 AM GMT) to support daily business reporting, prioritizing timeliness over instantaneous availability.

The SLI should act as a reliable proxy for user dissatisfaction. A dip in the SLI should consistently correspond to a negative user experience. This requires validating that the metric you are tracking is the right signal.

• Example: For a search service, tracking p95 latency may be a better indicator of general user frustration than average latency, which can be skewed by a few very fast requests.
• If the SLI is green but users are still complaining, the SLI is measuring the wrong thing and must be re-evaluated.

A Service Level Objective (SLO) is the quantitative, internal target derived from an SLI. It defines the acceptable level of reliability for a specific service metric over a defined period. An SLO is a goal, not a measurement.

• Example: An SLO might state that the service's request latency (the SLI) must be under 200ms for 99.9% of requests over a 30-day rolling window.
• Relationship to SLI: The SLI is the measured value; the SLO is the target value. You compare the SLI to the SLO to determine if the service is meeting its reliability goals.
• Purpose: SLOs create a clear, shared understanding of what "reliable enough" means for a service, enabling data-driven decisions about trade-offs between stability and innovation.

A Service Level Agreement (SLA) is a formal, external contract between a service provider and its customers. It defines the minimum acceptable service performance, often based on SLOs, and includes consequences for non-compliance.

• Key Components: An SLA typically includes the specific SLO targets, measurement methods, reporting procedures, and remedies (like service credits or financial penalties) if the SLOs are not met.
• Relationship to SLO/SLI: The SLA is the business contract informed by the internal engineering target (SLO), which is itself measured by the raw metric (SLI). SLAs are usually less aggressive than internal SLOs to provide a safety buffer.
• Purpose: SLAs manage customer expectations and establish legal and financial accountability for service reliability.

An Error Budget is the allowable amount of unreliability for a service, calculated as 100% - SLO. It quantifies how much failure is "budgeted" for a given period, turning reliability from a constraint into a manageable resource.

• Calculation: If a service has a 99.9% availability SLO, its error budget is 0.1% unreliability. Over a 30-day month, this equates to a budget of approximately 43.2 minutes of downtime.
• Core Concept: The error budget can be spent on deploying new features, performing risky migrations, or experiencing unexpected incidents. Once the budget is exhausted, the focus must shift to improving stability.
• Purpose: Error budgets provide a clear, objective framework for balancing the pace of innovation with the necessity of system stability, enabling faster, safer development cycles.

A Data SLO and a Data SLI apply SRE principles specifically to data products and pipelines, quantifying acceptable targets for data quality dimensions.

• Data SLI Examples:
  • Freshness: Percentage of data partitions updated within the expected time window.
  • Correctness: Percentage of records passing validation rules (e.g., non-negative revenue).
  • Completeness: Percentage of expected rows or columns that are non-null.
  • Availability: Percentage of time the dataset is queryable by downstream consumers.
• Data SLO Example: "99% of daily partition data must be available for querying by 06:00 UTC" (an availability SLO).
• Purpose: Data SLOs/SLIs move data quality from subjective assessment to objective, measurable engineering targets, allowing teams to prioritize fixes based on quantifiable impact to business processes.

Burn Rate is the speed at which a service consumes its Error Budget. It is a critical metric for incident response, indicating the severity and urgency of an ongoing reliability issue.

• Calculation: Expressed as the percentage of the total error budget consumed per unit of time (e.g., % per hour). A burn rate of 100% per hour means the entire monthly budget will be exhausted in one hour.
• Interpretation:
  • Slow Burn: A steady, low burn rate might indicate chronic, low-grade reliability issues.
  • Fast Burn: A high burn rate signals a severe, active incident requiring immediate attention.
• Purpose: Burn rate helps teams triage incidents. A fast burn rate triggers urgent, all-hands response, while a slow burn can be addressed through planned engineering work.

Mean Time to Resolution (MTTR) is a key reliability metric that measures the average elapsed time from the detection of a system failure or incident until it is fully resolved and normal service is restored.

• Components: MTTR encompasses several phases: Detection Time, Diagnosis Time, Mitigation Time, and Recovery/Repair Time.
• Relationship to SLIs: While SLIs like latency or error rate signal that something is wrong, a low MTTR depends on effective monitoring, runbooks, and automation to determine what is wrong and fix it quickly.
• Purpose: Improving MTTR is a primary goal of reliability engineering. A low MTTR minimizes the impact of incidents on the error budget and customer experience. It is often a more actionable target than aiming for zero failures.