Telemetry
API reliability SQL recipe

Measure API Availability Against an SLO

Calculate daily availability and show whether a service met its explicit objective.

Intermediateapi_requestsReviewed 2026-07-27Tested with Apache DataFusion 45.2.0

Question answered

Did each service meet its daily availability objective?

An SLO turns a reliability rate into a decision boundary. Keeping good events, total events, and objective together makes compliance review auditable.

Event contract

Fields the query expects

FieldTypeWhy it exists
timestamp_utcTimestampRequest completion time.
serviceUtf8Stable service name.
slo_eligibleBooleanWhether the request belongs in the SLO denominator.
slo_goodBooleanWhether the request satisfied the SLO.
DataFusion SQL

Copy the query

sql
SELECT
  date_trunc('day', timestamp_utc) AS day,
  service,
  SUM(CASE WHEN slo_eligible THEN 1 ELSE 0 END) AS eligible_requests,
  SUM(CASE WHEN slo_eligible AND slo_good THEN 1 ELSE 0 END)
    AS good_requests,
  100.0 * SUM(CASE WHEN slo_eligible AND slo_good THEN 1 ELSE 0 END)
    / NULLIF(SUM(CASE WHEN slo_eligible THEN 1 ELSE 0 END), 0)
    AS availability_pct,
  99.9 AS objective_pct
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '30 days'
GROUP BY date_trunc('day', timestamp_utc), service
HAVING SUM(CASE WHEN slo_eligible THEN 1 ELSE 0 END) > 0
ORDER BY day, service;

This read-only query is planned and executed against an empty typed table with Apache DataFusion 45.2.0. The deterministic sample output is synthetic and reviewed separately; validate field types, thresholds, and business definitions against your own data. Read the testing methodology.

Query result

Daily service availability

Query API missed the 99.9% objective on July 26.

dayserviceeligible_requestsgood_requestsavailability_pctobjective_pct
2026-07-25query_api182,400182,27499.9399.9
2026-07-26query_api176,820176,50199.8299.9
2026-07-27ingestion_api248,100247,97699.9599.9

Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.

How the SQL works

  1. 1Explicit eligibility protects the denominator from health checks or unsupported traffic.
  2. 2slo_good can encode both correctness and latency when the objective requires both.
  3. 3The objective is returned beside the observed value so charts and reviews preserve the decision boundary.

Edge cases to decide

  • Use complete time buckets for paging and compliance reports.
  • Document excluded traffic so the SLO cannot improve through silent denominator changes.
  • A daily view is useful for review; fast error-budget alerts usually need shorter windows.

Recommended dashboard

  • Trend: availability_pct with objective line
  • Stat: compliant days in the selected period
  • Table: bad events for missed service-days

Alert guidance

Use multi-window error-budget burn alerts for paging and this daily view for compliance review.

Read alert setup

Put the recipe to work

Related instrumentation and guides

Continue the analysis

Run it on real events

Create a table, adapt the fields, and save the result

Start free, send structured events, and use the query result as a chart, shared dashboard widget, or alert input.

Get an API key