Data Service Level Indicator (Data SLI)

A Data SLI must be expressed as a quantifiable metric, not a subjective assessment. It is typically a ratio, rate, or percentage derived from observable system events. This allows for objective tracking and comparison against a target threshold (the SLO).

• Examples: (Valid Records / Total Records) * 100 for validity, (Records Delivered On Time / Total Expected Records) for timeliness.
• Non-Example: "Data is mostly accurate" is not a valid SLI; "Data accuracy is 99.5%" is.

An effective Data SLI measures an aspect of the data product that directly impacts the consumer's ability to use it. It focuses on external, user-facing symptoms of data health, not internal pipeline details.

• Good SLI: "Percentage of dashboard queries returning data refreshed within the last hour" (measures freshness from the user's perspective).
• Poor SLI: "Kafka consumer lag is under 1000 messages" (an internal operational metric that may not directly correlate to user-visible issues).

Each Data SLI should map clearly to a core data quality dimension (e.g., freshness, completeness, accuracy) or a business outcome. This alignment ensures the metric is relevant and that improvements to the SLI translate to tangible value.

• Freshness SLI: Time elapsed since the source data was last successfully updated.
• Completeness SLI: Percentage of non-null values in critical fields.
• Accuracy SLI: Percentage of records matching a verified golden source.

The calculation for a Data SLI should be simple to explain, compute, and audit. Its definition must also be stable over time; frequent changes make historical trend analysis and SLO compliance meaningless. Complexity is managed in the underlying data contracts and validation logic, not in the SLI formula itself.

• Stable: "Daily record count for table X."
• Unstable (if changed): "Daily record count for table X, but excluding test users, and only if the source system flag is 'A' or 'B'." (Such filters should be part of the pipeline definition, not the SLI).

The primary operational purpose of a Data SLI is to track consumption of an error budget. The error budget is defined as 100% - SLO%. If the SLI's measured value falls below the SLO threshold, the error budget is consumed. Exhausting this budget triggers focused engineering review and remediation, shifting effort from feature development to reliability work.

• Example: With a Freshness SLO of 99.9% (allowing 0.1% error budget), an SLI measuring "freshness compliance" at 99.85% for a period consumes a portion of the allowable downtime.

It is critical to distinguish the SLI (the measurement) from the SLO (the target). The SLI is the "what we measure," such as "data freshness latency in minutes." The SLO is the "goal we aim for," such as "99% of data consumers receive data with freshness latency < 5 minutes." A single SLI can be used to evaluate multiple SLOs with different thresholds for different consumer tiers.

A Data Service Level Objective (Data SLO) is the target level of reliability for a data product, defined as a percentage of time that its Data SLIs must meet a predefined threshold. It is a formal agreement on the acceptable quality of service.

• Example: "99.9% of daily user records must be available for the 8 AM executive dashboard."
• The SLO is the goal; the SLI is the measurement used to determine if the goal is being met.

A Data Error Budget quantifies the allowable amount of unreliability for a data product, derived directly from its Data SLO. It represents the cumulative time a pipeline can fail to meet its SLOs before triggering a formal incident.

• Calculation: If an SLO is 99.9% monthly availability, the error budget is 0.1% of the month (~43.2 minutes).
• Purpose: It creates a shared, objective resource for balancing feature velocity against reliability. Teams can "spend" the budget on risky changes but must halt feature work to focus on stability if the budget is exhausted.

A Data Quality Dimension is a fundamental category or aspect used to characterize and measure the fitness of data. Data SLIs are the quantitative, operationalized measurements of these dimensions.

Core dimensions include:

• Freshness/Timeliness: Age of data at point of use.
• Completeness: Proportion of expected data present.
• Accuracy: Correctness of data values.
• Validity: Conformance to defined formats/rules.
• Consistency: Logical coherence across systems.
• Uniqueness: Absence of duplicate records.

An SLI like "p95 data freshness < 1 hour" operationalizes the timeliness dimension.

A Data Quality Gate is an automated checkpoint within a data pipeline that evaluates one or more Data SLIs against predefined thresholds. It enforces quality standards by halting processing or triggering alerts when violations occur.

• Implementation: Often a programmatic check in an orchestration tool (e.g., Apache Airflow, dbt) or a feature of a data observability platform.
• Example: A gate before a critical table is published that checks if the null rate for a key column exceeds 5% (violating a completeness SLI).
• Function: It prevents low-quality data from propagating downstream, turning SLI measurements into actionable controls.

A Data Health Index is a high-level, composite metric that synthesizes multiple Data SLIs and operational statuses into a single, often business-facing score indicating the overall fitness-for-use of a data asset or pipeline.

• Composition: It may aggregate SLIs for freshness, completeness, and accuracy, weighted by business criticality.
• Purpose: Provides an at-a-glance status for executives and data consumers, abstracting technical SLIs into a simple indicator (e.g., "Healthy," "Degraded," "Critical").
• Contrast with SLI: An SLI measures one specific aspect; a Health Index provides a holistic view.

Data Downtime is a reliability metric that quantifies the total period a dataset is inaccurate, missing, or otherwise unfit for use. It is directly measured by tracking violations of Data SLIs over time.

• Calculation: Sum of all time intervals where key SLIs (e.g., freshness, completeness) are outside their SLO thresholds.
• Impact: It translates technical SLI breaches into a business-understandable metric of lost utility, analogous to application downtime.
• Example: If a customer table's completeness SLI is violated for 2 hours, that contributes 2 hours to the dataset's total data downtime.