Event schema
Fields the query expects
| Field | Type | Why it exists |
|---|---|---|
| timestamp_utc | Timestamp | Request completion time. |
| service | Utf8 | Stable service name. |
| slo_eligible | Boolean | Whether the request belongs in the SLO denominator. |
| slo_good | Boolean | Whether the request satisfied the SLO. |
Copy the query
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. We review the synthetic sample output separately. Check field types, thresholds, and counting rules against your own data. Read the testing methodology.
Query result
Daily service availability
Query API missed the 99.9% objective on July 26.
2026-07-25
99.93%
2026-07-26
99.82%
2026-07-27
99.95%
| day | service | eligible_requests | good_requests | availability_pct | objective_pct |
|---|---|---|---|---|---|
| 2026-07-25 | query_api | 182,400 | 182,274 | 99.93 | 99.9 |
| 2026-07-26 | query_api | 176,820 | 176,501 | 99.82 | 99.9 |
| 2026-07-27 | ingestion_api | 248,100 | 247,976 | 99.95 | 99.9 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
Reproduce the example
Download the sample data
The JSON bundle includes the event schema with field types, illustrative input rows, exact SQL, expected output, review notes, and engine version. The CSV contains the displayed result.
How the SQL works
- 1Explicit eligibility protects the denominator from health checks or unsupported traffic.
- 2slo_good can encode both correctness and latency when the objective requires both.
- 3The query returns the target beside the measured value so charts show whether the service met it.
Edge cases to check
- 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 setupSet up the events this query needs
Related instrumentation and guides
Continue the analysis
Calculate API error rate by route
Rank API routes by 5xx error rate. Exclude routes with fewer than 20 requests so one failure does not dominate the results.
Open recipeCalculate p50, p95, and p99 API latency
Compare median and tail latency by endpoint with DataFusion-compatible percentile SQL.
Open recipeCalculate API error-budget burn rate
Turn hourly request failures into an SLO burn-rate series that shows how quickly the allowed error budget is being consumed.
Open recipeRun it on your 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.