SLIs SLOs For Data Products

Why this matters

Data products power reports, ML features, and APIs. SLIs and SLOs turn vague "quality" into measurable, shared commitments. As a Data Platform Engineer, you will be asked to: define reliable data contracts, decide alert thresholds, track data downtime, and negotiate trade-offs using error budgets. Clear SLIs/SLOs reduce noisy alerts, prevent dashboard outages, and align teams on what "good" looks like.

Who this is for

• Data Platform Engineers and Data Engineers designing pipelines and data products
• Analytics Engineers setting quality gates for models and marts
• ML/Data Scientists who need dependable features and training data

Prerequisites

• Basic understanding of batch and streaming pipelines
• Familiarity with data quality dimensions (freshness, completeness, accuracy, schema)
• Comfort with metrics, time windows, and alerting concepts

Concept explained simply

Definitions

• SLI (Service Level Indicator): the measured number (e.g., freshness delay, % rows passing checks).
• SLO (Service Level Objective): the target and window for the SLI (e.g., 99% of days with delay ≤ 15 minutes, measured monthly).
• Error budget: how much unreliability is allowed while still meeting the SLO (e.g., 1% monthly).

Mental model

Treat each dataset, feature set, or analytic view as a "product" with users and promises. SLIs are the vital signs; SLOs are the healthy ranges. Error budgets are how you decide when to pause feature work to improve reliability.

Worked examples

Example 1: Daily sales mart (batch)

Context: A table needs to be available for BI by 06:00 UTC daily.

• SLI (Freshness): on-time delivery = load_completed_time ≤ 06:00 UTC.
• SLO: 99% of days per calendar quarter are on time.
• Error budget: 1% of days per quarter (about 0.9 days/month).
• Alerting: Page when 2 consecutive misses or projected burn > 100% mid-quarter.

Example 2: Streaming features for fraud model

Context: Events from Kafka to a feature store must be fast.

• SLI (Latency): % events with end-to-end delay ≤ 2 minutes.
• SLO: 99.5% rolling 30-day window.
• Error budget: 0.5% of events per 30 days.
• Guardrails: If burn rate > 2x over 6 hours, throttle feature changes; escalate.

Example 3: Customer 360 completeness

Context: A unified customer table feeds marketing journeys.

• SLI (Completeness): % of active customers with a primary email populated.
• SLO: ≥ 98% rolling 28 days.
• Secondary SLI (Validity): % emails matching format and domain rules.
• Note: If upstream source is down, track "attributed downtime" separately to inform contracts.

Learning path

1. Identify users and key journeys: what decision or model depends on this data?
2. Pick 2–3 SLIs: choose the fewest metrics that represent user pain (freshness, completeness, validity).
3. Baseline: measure current SLIs for 2–4 weeks to see natural variability.
4. Set SLOs: choose realistic targets plus an error budget. Agree on window (rolling vs calendar) and alert policy.
5. Instrument: add monitors/tests; emit metrics with timestamps and labels (dataset, version, region).
6. Operate: review weekly, track burn, run retros on misses, and evolve targets as usage changes.

Common mistakes and self-check

• Too many SLIs: dilutes focus; keep 2–3 per product.
• Vanity SLOs: 100% targets create alert fatigue; choose achievable objectives.
• Unclear windows: saying "99%" without defining 7/28/30-day window.
• Measuring proxies only: e.g., job success without checking data validity.
• No attribution: all incidents look the same; separate upstream vs internal issues.
• Static targets: never revisiting SLOs after user growth or architecture changes.

Self-check

• Can you explain how a user would notice a breach?
• Is each SLI automatically measurable from logs/monitors?
• Do alerts trigger before the error budget is fully consumed?
• Is there a clear escalation when burn rate spikes?

Practical projects

• Instrument a batch table with freshness and completeness SLIs, publish a weekly SLO report, and add a
  burn-rate alert policy

  Alert if projected monthly burn exceeds 100% based on the last 3 days of performance or if there are 2 consecutive misses.

• For a small stream pipeline, measure end-to-end latency and define a 99% 5-minute SLO. Simulate lag by pausing a consumer and observe burn.
• Add data validity tests (e.g., primary key uniqueness, null checks) and convert pass rates into an SLI and SLO with rollup dashboards.

Practice exercises

Complete the tasks below. Then try the Quick Test. Note: The test is available to everyone; only logged-in users get saved progress.

Exercise 1 — Draft SLIs and SLOs for a daily orders product

Context: A daily orders table powers finance and BI. Upstream sources: OLTP DB and a payments API. Users need data by 07:00 UTC.

1. Pick 3 SLIs that reflect user pain (freshness, completeness, validity).
2. Set realistic SLO targets and windows.
3. Write a short policy snippet summarizing SLIs, SLOs, and alerting.

Exercise 2 — Calculate error budget burn

Context: Freshness SLO: 95% of days the table is ready by 07:00 UTC in a 30-day month. This month there were 2 days late.

1. Compute SLI.
2. Compute error budget (days and percent).
3. Compute burn percentage and state if you met the SLO.

Exercise completion checklist

• You used 2–3 SLIs focused on user outcomes.
• Each SLO includes a target and a time window.
• Alerting is tied to burn rate or short-term breach patterns.

Mini challenge

Your ML team complains about degraded model performance each Monday morning. You discover late-arriving events from Friday evenings. Propose one SLI and SLO to address this, and one operational change to reduce burn without over-tightening the SLO.

Get ready for the Quick Test

You can take the Quick Test now. Everyone can access it; only logged-in users will have their progress saved.