Service Level Objective (SLO)

An SLO must be expressed as a numerical target derived from a Service Level Indicator (SLI). It is not a qualitative goal like "good performance." The target is typically a percentage or threshold over a specific time window.

• Example: "99.9% of API requests must have a latency under 200ms over a 30-day rolling window."
• The associated SLI measures request latency, and the SLO defines the acceptable success rate for that measurement.

An SLO is an internal engineering target used to guide development and operational priorities. It is distinct from a Service Level Agreement (SLA), which is an external contract with customers that may include financial penalties. The SLO should be set more aggressively than the SLA to provide a safety buffer and ensure the SLA is consistently met.

• Purpose: To give teams a clear, shared understanding of what "reliable enough" means for their service.
• Outcome: Enables data-driven decisions about prioritizing new features versus stability work.

Effective SLOs measure aspects of the service that directly impact end-user happiness or business outcomes. They should not be based on internal system metrics that are invisible to users unless those metrics are proven proxies for user experience.

• Good SLI/SLO: Availability measured as the fraction of successful HTTP requests from the user's perspective.
• Poor SLI/SLO: CPU utilization on a backend server, which is an internal operational detail.
• The focus ensures engineering effort is aligned with what users actually care about.

The SLO's complement is the Error Budget. If an SLO is 99.9% availability, the Error Budget is 0.1% unreliability, or the allowable time the service can be "broken" over the SLO window.

• Calculation: Error Budget = 1 - SLO
• Function: The Error Budget is a resource for innovation. It quantifies how much risk the team can take with releases and changes. Consuming the budget too quickly triggers a focus on stability.
• This creates a balanced, objective framework for managing the trade-off between velocity and reliability.

An SLO must be evaluated over a defined rolling time window (e.g., 28 days, 30 days, 90 days). This prevents short-term incidents from being forgotten and ensures the service maintains long-term reliability.

• Why it matters: A 99.9% monthly SLO allows for approximately 43 minutes of downtime per month. A team cannot "bank" reliability from a good previous month to offset a bad current month.
• The window length is a strategic choice: shorter windows (e.g., 7 days) increase sensitivity to problems; longer windows (e.g., 90 days) provide a more stable, long-term view.

In Data Reliability Engineering, SLOs are defined for data pipelines and products, focusing on dimensions critical to data consumers.

• Common Data SLO Types:
  • Freshness: Data is no older than X minutes/hours from the source event.
  • Completeness: At least Y% of expected records arrive.
  • Correctness: Less than Z% of records fail validation or business logic checks.
  • Availability: The dataset or table is queryable and accessible.
• Data Error Budgets derived from Data SLOs govern the trade-off between shipping new data features and maintaining data health and trust.

A Service Level Indicator (SLI) is the foundational quantitative measure of a specific aspect of a service's performance. For data systems, this is the raw metric used to evaluate compliance with an SLO.

• Examples: Data freshness (e.g., 'p95 event-time latency < 5 minutes'), data correctness (e.g., 'schema validation success rate'), or data completeness (e.g., 'percentage of non-null required fields').
• Role: An SLI provides the direct, measurable signal. An SLO is the target set for that signal.

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 incorporating SLOs, and specifies consequences for non-compliance.

• Key Difference: An SLO is an internal engineering target for reliability. An SLA is an external business contract with legal and financial implications.
• Typical Elements: Includes defined SLOs, measurement methods, reporting procedures, and remedies (e.g., service credits, financial penalties) if the SLA is breached.

An Error Budget quantifies the allowable unreliability for a service, calculated as 100% - SLO. It operationalizes the SLO by providing a consumable resource for balancing innovation velocity with system stability.

• Mechanism: If an SLO is 99.9% availability per month, the error budget is 0.1% unreliability, or approximately 43.2 minutes of downtime.
• Usage: Engineering teams can 'spend' this budget on risky changes or deployments. Exhausting the budget triggers a focus on stability work.

A Data SLO is a Service Level Objective specifically defined for a data product, pipeline, or asset. It quantifies acceptable targets for data-quality dimensions critical to downstream consumers and business processes.

• Common Types:
  • Freshness SLO: Maximum acceptable data age (e.g., '95% of records arrive within 1 hour of event time').
  • Correctness SLO: Maximum acceptable rate of invalid data (e.g., 'field validation pass rate > 99.99%').
  • Completeness SLO: Minimum acceptable data coverage (e.g., '> 99.5% of expected daily partitions are non-empty').

Burn Rate is the speed at which a service consumes its Error Budget, typically expressed as the percentage of the total budget consumed per hour. It is a critical metric for gauging the severity of an ongoing reliability incident.

• Calculation: (Error Budget Consumed) / (Time Period). A burn rate of 100% per hour means the entire monthly budget will be exhausted in one hour.
• Alerting: Fast burn rates (e.g., > 10% per hour) trigger urgent, page-worthy alerts. Slow burn rates might only warrant a ticket.

An Error Budget Policy is a formal organizational rule that dictates how an Error Budget is managed. It defines the actions triggered at specific budget consumption levels, creating a deterministic link between reliability measurements and engineering behavior.

• Example Policy: 'When 50% of the monthly error budget is consumed, a freeze is placed on all non-critical deployments. At 100% consumption, all feature work stops until reliability is restored.'
• Purpose: Removes subjectivity from operational decisions, ensuring SLOs are meaningful drivers of prioritization.