48.3k Log in Get started
Metric · Observability

What is SLO compliance, and how do you measure it in Metabase?

SLO compliance is reliability judged against a promise: how actualavailability (or latency, or freshness) compares to an explicit service-level objective, and how much error budget remains. It's the metric that turns "99.2% this month" into "fine" or "breach." Measure it in Metabase from SLO definitions plus health rollups synced from Honeycomb, Datadog, Prometheus, or Grafana.

TL;DR — Budget consumed = (1 − actual) ÷ (1 − target); 100% means the budget is gone. Track the burn rate too — it's the early warning that predicts the breach before it happens.

What SLO compliance measures

It measures whether reliability is meeting an agreed bar — and how much room is left for planned risk like deploys and migrations. The error budget reframes reliability as a resource to spend: a team with budget left can ship faster; a team that's burned it slows down and stabilizes. That makes this the rare reliability metric that directly informs delivery decisions.

What data does it need?

  • slo_definitions: service, objective (e.g. 99.9), indicator type, and window.
  • service_health_rollups with good/total counts per window — or the source tool's SLO status API results synced daily.
  • Optional incidents to attribute budget burn to specific events.

SQL patterns

Error budget consumed this month, by servicePostgreSQL
WITH actuals AS (
  SELECT
    r.service_name,
    s.slo_target,
    100.0 * SUM(r.successful_requests) / NULLIF(SUM(r.total_requests), 0)
      AS actual_pct
  FROM service_health_rollups r
  JOIN slo_definitions s ON s.service_name = r.service_name
  WHERE r.window_start >= date_trunc('month', CURRENT_DATE)
  GROUP BY r.service_name, s.slo_target
)
SELECT
  service_name,
  slo_target,
  ROUND(actual_pct, 3) AS actual_pct,
  ROUND(
    100.0 * (100.0 - actual_pct) / NULLIF(100.0 - slo_target, 0), 1
  ) AS budget_consumed_pct
FROM actuals
ORDER BY budget_consumed_pct DESC;
Daily burn rate (1.0 = exactly on budget)PostgreSQL
SELECT
  service_name,
  date_trunc('day', window_start) AS day,
  ROUND(
    (1.0 - 1.0 * SUM(successful_requests) / NULLIF(SUM(total_requests), 0))
    / NULLIF((100.0 - MAX(slo_target)) / 100.0, 0), 2
  ) AS burn_rate
FROM service_health_rollups
WHERE window_start >= CURRENT_DATE - INTERVAL '28 days'
GROUP BY 1, 2
ORDER BY 1, 2;

Pitfalls

Measuring compliance without published targets.→ An SLO nobody agreed to is just a chart. Publish the objectives — with owners — before building the dashboard.
Watching budget remaining but not burn rate.→ Budget says where you are; burn rate says where you'll be. A fast burn with plenty of budget left still deserves a page.
Setting the SLO at 100%.→ A perfect target means zero error budget — every blip is a breach and deploys become terrifying. Leave room to spend.
One SLO for every service.→ Tiers exist for a reason: payments and prefetch endpoints don't share a bar. Define objectives per service tier.

Where this metric applies

Metrics

Service availabilityError rateMTTR

Dashboards

SLO tracking dashboardService availability dashboard

FAQ

SLI, SLO, SLA — what's the difference?
The SLI is the indicator you measure — availability, latency, freshness. The SLO is the internal objective for that indicator (99.9% over 28 days). The SLA is the external contract with penalties attached. Dashboards track SLIs against SLOs; lawyers handle SLAs. In practice, set the SLO stricter than any SLA, so the SLO tracking dashboard warns you long before a contractual breach is in sight.
What is a burn rate, exactly?
The rate you're consuming error budget relative to plan. Burn rate 1.0 spends the budget exactly by period end; 2.0 spends it in half the period. It's the early-warning half of SLO reporting — budget consumed says where you are, burn rate says where you'll be. Multi-window burn-rate alerts (fast + slow) are the standard SRE paging pattern, and tools like Honeycomb and Grafana expose burn data you can sync and chart.
Can I track SLOs on things other than availability?
Anything with a good/total indicator and an agreed target fits the same budget math: latency (share of requests under a threshold), pipeline freshness, durability, even support response time. The availability SLO is just the most common instance. Keep each objective in slo_definitions with its indicator type and window, and the budget-consumed and burn-rate queries work unchanged across all of them on one SLO tracking dashboard.
How do you calculate error budget consumed?
Budget consumed = (1 − actual) ÷ (1 − target). With a 99.9% target the budget is 0.1% unreliability; if actual availability lands at 99.95%, you've consumed 50% of it, and at 100% consumed any further failure is a breach. Compute actuals from service_health_rollups as successful over total requests — the same math as service availability — joined to slo_definitions, and rank services by budget consumed so the SLO tracking dashboard leads with the riskiest.
How do you track SLO compliance in Metabase?
Sync two tables: slo_definitions (service, objective, indicator, window) and service_health_rollups with good/total counts — from Honeycomb, Datadog, or Prometheus counters. Chart budget consumed per service for the current window and daily burn rate as the early warning, then pair the result with incident count to attribute budget burn to specific events.