Data SLO

Freshness measures the timeliness of data, defining the maximum acceptable delay between a real-world event and its availability for consumption. It is critical for time-sensitive decisions.

• Example SLO: "95% of daily sales records must be available in the data warehouse within 15 minutes of the transaction closing."
• Common SLIs: Data latency (end-to-end), ingestion lag, processing delay.
• Impact: Stale data leads to incorrect analytics, missed opportunities, and operational blind spots.

Completeness quantifies the presence of expected data, ensuring that all required records and fields are delivered. It guards against silent data loss.

• Example SLO: "99.9% of expected sensor readings from all manufacturing lines must be present in the hourly aggregate table."
• Common SLIs: Percentage of non-null fields, record count vs. expected count, partition completeness.
• Impact: Missing data skews aggregates, breaks joins, and invalidates machine learning features.

Correctness measures the accuracy and validity of data values against defined business rules and schemas. It ensures data reflects reality.

• Example SLO: "Less than 0.1% of customer records may contain invalid email addresses or out-of-range age values."
• Common SLIs: Schema validation failure rate, business rule violation rate, anomaly detection alerts.
• Impact: Incorrect data directly leads to faulty business intelligence, poor model predictions, and compliance risks.

Availability defines the proportion of time a data asset or pipeline endpoint is accessible and queryable by its consumers. It is a foundational reliability metric.

• Example SLO: "The customer dimension table must have 99.95% query availability over a rolling 30-day window."
• Common SLIs: Successful query rate, API uptime, pipeline runtime success rate.
• Impact: Unavailable data halts downstream processes, dashboards, and applications, causing operational stoppages.

Throughput measures the volume of data a pipeline can process within a given timeframe, ensuring it meets scaling demands. It is a capacity and performance dimension.

• Example SLO: "The streaming pipeline must sustain an ingestion rate of 50,000 events per second during peak load."
• Common SLIs: Records processed per second, bytes processed per minute, job execution duration.
• Impact: Insufficient throughput creates backlogs, increases latency, and can cause cascading failures across dependent systems.

Lineage Integrity ensures the accurate, unbroken tracking of data provenance and transformations from source to consumption. It is essential for debugging and trust.

• Example SLO: "100% of data assets in the production zone must have their upstream sources and transformation logic documented and accessible."
• Common SLIs: Percentage of tables with populated lineage metadata, detection of broken dependency links.
• Impact: Broken lineage obscures the impact of source issues, complicates root cause analysis, and undermines data governance.

The first step is a business-centric inventory to determine which datasets, tables, or data products are mission-critical. Not all data requires an SLO. Focus on assets that directly power key business decisions, customer-facing applications, or revenue-generating models.

Key activities include:

• Mapping data lineage to understand downstream consumers.
• Interviewing stakeholders (e.g., product managers, analysts, data scientists) to assess business impact.
• Prioritizing assets based on their role in core business processes, regulatory reporting, or model training.

For each critical asset, define the Service Level Indicators (SLIs) that quantify its health. A Data SLI is a specific, measurable property. Common dimensions include:

• Freshness: Age of the most recent data update (e.g., (current_time - max(event_time)) < threshold).
• Completeness: Percentage of expected records or non-null fields present.
• Correctness: Rate of records passing validation rules or matching source systems.
• Availability: Percentage of time the data asset is queryable and serving requests.

Each SLI must have a precise calculation method and a reliable data source for measurement.

Transform SLIs into Service Level Objectives (SLOs) by attaching a quantitative target and a measurement window. This defines what "good" looks like. Targets should be ambitious but achievable, balancing user expectations with engineering reality.

Example SLO Statement: "99% of records in the customer_transactions table must be available for querying within 5 minutes of the transaction event time, measured over a 30-day rolling window."

Key considerations:

• Target Percentage: Often starts at 99% or 99.9% for critical assets.
• Measurement Window: Typically 28 or 30 days to smooth over daily/ weekly cycles.
• Error Budget: Implicitly defined as 100% - SLO Target. A 99.9% SLO grants a 0.1% error budget.

Implement automated systems to continuously compute SLIs and track SLO compliance. This requires robust instrumentation within data pipelines and storage systems.

Technical implementation involves:

• Embedding telemetry to capture timestamps, record counts, and validation results.
• Calculating SLI metrics in a time-series database (e.g., Prometheus, Datadog).
• Setting up alerting on error budget burn rate, not on individual SLI breaches. For example, alert if 50% of the monthly error budget is consumed in 6 hours, signaling a rapid degradation.
• Creating dashboards for real-time SLO status visibility for engineering and stakeholder teams.

Operationalize the Data SLO by making it a central governance mechanism. The error budget derived from the SLO becomes a key resource for decision-making.

Integration points include:

• Release Gates: Halting deployments of new pipeline features if the error budget is depleted.
• Prioritization: Using remaining error budget to justify investing in reliability work over new features.
• Postmortems: Analyzing significant error budget consumption to drive systemic improvements.
• Game Days: Proactively testing pipeline resilience and recovery procedures to validate SLO assumptions under failure conditions.

Data SLOs are not set-and-forget. They require periodic review and adjustment based on operational experience and evolving business needs.

Regular review cadence should address:

• Is the SLO target too loose (never breached) or too strict (constantly breached), leading to alert fatigue?
• Have consumer requirements changed, necessitating a stricter freshness or correctness target?
• Can measurement methods be improved for greater accuracy or lower overhead?
• Are the SLOs effectively influencing engineering behavior and improving data product reliability?

This iterative process ensures SLOs remain relevant, valuable, and aligned with business objectives.

A Service Level Indicator (SLI) is the quantitative, measured value of a specific aspect of a data product's performance or quality. It is the raw metric used to evaluate compliance with a Data SLO.

• Examples for Data: Freshness (p95 latency), Completeness (% of non-null records), Correctness (% of records passing validation).
• Key Property: An SLI must be measurable, observable, and directly tied to user experience.

A Service Level Agreement (SLA) is a formal, external contract between a data provider and its consumers (internal or external) that defines the minimum acceptable service level, often with associated consequences for breach.

• Relationship to SLO: An SLA is typically less aggressive than the internal SLO, providing a buffer. Violating an SLO consumes the error budget; violating an SLA may trigger financial penalties or credits.
• Focus: SLAs are business and legal documents, while SLOs are engineering targets.

An Error Budget is the allowable amount of unreliability for a data product, calculated as 100% - SLO. It quantifies the trade-off between innovation velocity and reliability.

• Function: It is a resource to be spent on releases, experiments, and technical debt. Once depleted, the focus must shift to improving reliability.
• Data Context: A Data Error Budget might be spent on schema changes, pipeline optimizations, or accepting known data quality issues for a period to enable a new feature.

A Data Freshness SLO defines the maximum acceptable age of data, specifying the latency between a real-world event and its availability for consumers.

• Example: "99% of order records must be available in the analytics warehouse within 5 minutes of the transaction."
• Measurement: Typically uses p95 or p99 latency as the SLI. Critical for real-time dashboards, fraud detection, and operational reporting.

A Data Correctness SLO defines the maximum acceptable rate of inaccurate, invalid, or misleading values within a dataset, as defined by business logic or validation rules.

• Example: "The calculated revenue field must match the source system's audit trail with 99.95% accuracy."
• Implementation: Requires robust data validation rules, anomaly detection on derived metrics, and reconciliation processes with source systems.

A Data Completeness SLO defines the minimum acceptable percentage of expected data records or required fields that must be present and non-null for a dataset to be considered usable.

• Example: "The customer events table must contain at least 99.9% of the events logged by the production application."
• Challenges: Requires knowing the expected volume or cardinality, often via heartbeat monitors or independent counters at the data source.