Features
Data SLAs are external, contractual promises about data availability, freshness, or quality, while SLOs are internal, measurable targets that indicate whether the SLA is on track.
SLAs (Service-Level Agreements) are the promises you make to customers about data reliability. SLOs (Service-Level Objectives) are the measurable targets you track internally to keep those promises. Getting this right prevents late dashboards, broken ML models, and sleepless on-call rotations.
Modern companies run on analytics, metrics, and machine-learning models. If a key metric is delayed or a feature pipeline delivers stale data, revenue-driving decisions get blocked. Defining clear SLAs and SLOs lets teams quantify how reliable their data must be and gives stakeholders the confidence to build on top of it.
A quantitative measure of some aspect of the service. Examples: “hours since last successful load,” “percentage of rows failing a quality check,” or “95th-percentile query latency.”
A target value or range for an SLI, set by the data team. Example: “Pipeline freshness < 15 minutes 99% of the time.”
A formal commitment to customers or downstream teams that you will meet one or more SLOs over a defined time window. Breaching an SLA typically triggers escalation, credits, or public reporting.
Suppose Finance needs yesterday’s booked-revenue dashboard by 8 a.m. EST. You might set:
You can store SLI metrics in a monitoring table and query them programmatically.
-- Daily aggregation of freshness SLI
INSERT INTO monitoring.pipeline_freshness (load_date, minutes_late)
SELECT CURRENT_DATE, EXTRACT(EPOCH FROM NOW() - MAX(loaded_at)) / 60
FROM raw.revenue_transactions;
-- Query to test the SLO over the last 90 days
SELECT
100.0 * SUM(CASE WHEN minutes_late <= 15 THEN 1 ELSE 0 END) / COUNT(*) AS pct_fresh_within_target
FROM monitoring.pipeline_freshness
WHERE load_date >= CURRENT_DATE - INTERVAL '90 days';
Work backward from when stakeholders need data. Build buffers to account for upstream variability.
Store SLI results in a metrics layer (e.g., Prometheus, BigQuery, or a dedicated table) for reliability audits.
Like in software SRE, an error budget defines how many SLO violations are tolerable before pausing risky changes.
Re-evaluate SLAs/SLOs every quarter as data volume, pipelines, or business needs evolve.
Saying “our SLA is 95% freshness” causes confusion. The SLA is the promise; the SLO is the internal target that supports it. Fix by clearly documenting both.
“Data must be high quality” is meaningless without a quantifiable SLI such as “null-rate < 0.5%.” Attach numeric thresholds.
Pipelines often depend on external APIs or operational DBs. Account for their reliability in your error budget; otherwise your SLOs will be impossible to hit.
While Galaxy is primarily a SQL editor, its run history and shareable, endorsed queries make it easy to standardize the SLI queries that power your SLO dashboards. Embed your monitoring SQL in a Galaxy Collection, endorse the canonical version, and let analysts reuse it without forking ad-hoc code.
Without clear SLAs, stakeholders receive no guarantee that dashboards or ML features will be timely and accurate. Without SLOs, engineers lack measurable goals and early-warning alerts. Together, SLAs and SLOs translate business reliability requirements into actionable engineering metrics, aligning data teams with customer expectations and avoiding costly incidents.
The SLA is the public, contractual promise to stakeholders, while the SLO is an internal, measurable objective that supports keeping that promise.
One SLA can map to multiple SLOs—e.g., freshness and data quality—but keep the set minimal to avoid alert fatigue.
Yes. Store your SLI queries in a Galaxy Collection, endorse them, and schedule external orchestration (e.g., Airflow) to run them. Galaxy preserves run history and makes results shareable.
Quarterly reviews are common, or whenever data volume, pipeline logic, or business requirements change significantly.
.avif){kind=logo}
