Data SLI (Service Level Indicator)

A Data SLI must be a quantifiable metric derived from observable telemetry. It is not a subjective assessment. Examples include:

• Freshness: (Records delivered on time / Total records expected) * 100
• Completeness: (Non-null records / Total records) * 100
• Accuracy: (Records passing validation rules / Total records) * 100
• Latency: P99 time from source event to table update These are expressed as ratios, percentages, or distributions over a defined measurement window.

An effective SLI measures an aspect of data quality that directly impacts downstream consumers and business outcomes. It answers the question: "What does the user of this data product care about?"

• For a dashboard: Freshness is critical.
• For a machine learning feature store: Completeness and distribution stability are key.
• For financial reporting: Accuracy is paramount. The SLI must be tied to a clear, achievable SLO that, if violated, triggers a meaningful operational response.

SLIs are not point-in-time measurements; they are aggregated over a specific rolling time window. This window defines the evaluation period for SLO compliance.

• Common windows: 28-day or 30-day rolling periods.
• Calculation: The SLI value (e.g., 99.9% freshness) is the result of aggregating all measurement samples within that window. This temporal aggregation smooths out brief anomalies and provides a stable basis for error budget calculation, ensuring the SLO reflects sustained performance.

Each SLI is scoped to a discrete, identifiable data asset or pipeline. It does not measure the health of an entire platform vaguely.

• Scope Examples: A specific database table, a Kafka topic, a materialized view, or an API endpoint serving data.
• Ownership: The scoping implies clear data product ownership, enabling accountability. A customer_orders table has different SLIs than a web_clickstream topic. This precise scoping is essential for effective incident triage and root cause analysis when SLI performance degrades.

SLI measurement must be fully automated through instrumentation in the data pipeline. Manual checks are not scalable or reliable.

• Implementation: Achieved via data observability platforms that inject telemetry hooks to collect metrics on freshness, volume, schema, and lineage.
• Integration: SLI dashboards and alerts are fed directly from this telemetry, often using tools like Grafana or platform-native UIs.
• Key Practice: This aligns with Data Monitoring as Code, where SLI definitions are version-controlled configurations.

The SLI is the raw measurement; the Data SLO is the target threshold for that measurement (e.g., "Freshness SLI >= 99.5%").

• Error Budget: Derived directly from the SLO. If the SLO is 99.5% over 30 days, the error budget is 0.5% unreliability, or approximately 3.6 hours of "downtime."
• Governance Function: This framework creates a data-driven feedback loop. Consuming the error budget on firefighting triggers a review of pipeline stability and investment priorities. Thus, a well-defined SLI enables Data Reliability Engineering (DRE) practices.

Measures whether all expected data records have been successfully delivered and processed, guarding against silent data loss.

• Primary SLI: (Records received / Records expected) * 100
• Example: A nightly batch job expecting 10 million transaction records uses an SLI to verify 100% arrival. A drop to 95% triggers an alert.
• Related Metrics: Row count variance, file count checks, and ensuring no missing partitions or slices in time-series data.

Measures the correctness and adherence of data to defined schemas, formats, and business rules.

• Primary SLI: (Records passing validation rules / Total records processed) * 100
• Examples:
  • Schema Conformance: Percentage of records matching the expected column types and nullability constraints.
  • Business Rule Adherence: Percentage of financial transactions where debit + credit = 0.
  • Referential Integrity: Percentage of foreign key values that have a corresponding primary key in the parent table.

Measures the accessibility and readiness of a data asset or pipeline endpoint for consumption.

• Primary SLI: (Successful queries or accesses / Total attempts) * 100
• Measurement: Often calculated via synthetic probes that attempt to read from a table, API, or materialized view at regular intervals.
• Distinction: This SLI focuses on the service being reachable and responsive, not the internal quality of the data itself. It is closely tied to pipeline execution success rates.

Measures the fidelity of data to real-world entities and processes, often requiring cross-system reconciliation.

• Primary SLI: (Records reconciling with source of truth / Total records) * 100
• Complex Example: In an e-commerce pipeline, the SLI could be the percentage of orders where the pipeline's calculated total_revenue matches the sum of individual item charges in the transactional billing system.
• Implementation: Often requires dual-write checks or end-to-end reconciliation jobs that compare aggregated metrics across different systems.

Measures the statistical shape and integrity of data values to detect drift or duplication.

• Common SLIs:
  • Uniqueness: (Count of distinct values in a key column / Total row count) * 100. An SLI target might be 100% for primary keys.
  • Distribution Stability: Tracking the KL divergence or population stability index (PSI) for critical column values (e.g., country_code distribution) compared to a historical baseline. A significant shift indicates potential data corruption or source change.

A Data Service Level Objective (SLO) is the target level of reliability, expressed as a percentage over a measurement period, for a specific data quality characteristic measured by a Data SLI. It is the business goal derived from the indicator.

• Example: "99.9% of daily sales records must be available and accurate by 6 AM UTC."
• Relationship to SLI: The SLI is the measured metric (e.g., percentage of accurate records). The SLO is the target for that metric (e.g., 99.9%).

A Data Error Budget is the explicit, allowable amount of unreliability, derived from a Data SLO, that a data pipeline or system can consume before triggering a formal review or remediation effort. It quantifies risk tolerance.

• Calculation: If the SLO is 99.9% freshness over 30 days, the error budget is 0.1% of that period, or 43.2 minutes of stale data.
• Purpose: It frames data incidents not as failures to be punished, but as a shared resource to be managed. Exhausting the budget triggers a blameless post-mortem and investment in reliability.

Data Reliability Engineering (DRE) is the application of Site Reliability Engineering (SRE) principles to data systems. It is the overarching discipline that operationalizes Data SLIs, SLOs, and Error Budgets.

• Core Practices: Defining SLIs/SLOs, implementing error budgets, automating remediation, and conducting blameless post-mortems for data incidents.
• Goal: To systematically measure and improve the reliability, trustworthiness, and operational health of data products and pipelines.

Data Downtime is a period during which a dataset is incomplete, inaccurate, stale, or otherwise unfit for its intended use. It is the negative outcome that Data SLIs are designed to measure and SLOs are designed to limit.

• Analogy: Equivalent to application downtime for software services.
• Causes: Pipeline failures, schema breaks, source system outages, or undetected quality degradation.
• Impact: Directly consumes the Data Error Budget and can halt downstream analytics, machine learning inference, and business operations.

A Data Contract is a formal, versioned agreement between a data producer and consumer that specifies the schema, semantics, freshness, and quality guarantees of a data product. Data SLIs often serve as the measurable guarantees within a contract.

• Components: Schema definition, SLI/SLA commitments, evolution rules, and breach protocols.
• Monitoring: Data Contract Monitoring involves automatically validating that the live data stream adheres to the contract's SLI commitments, triggering alerts on violation.

A Data Health Score is a composite, quantitative metric that aggregates various data quality and reliability indicators—such as freshness, completeness, volume, and accuracy—into a single, normalized value representing the overall fitness-for-use of a data asset.

• Relationship to SLIs: Individual Data SLIs (e.g., freshness SLI, completeness SLI) are the input signals used to calculate the composite health score.
• Use Case: Provides a high-level, at-a-glance view of data asset status for product managers and executives, while engineers drill down into specific SLIs for debugging.