Event contract
Fields the query expects
| Field | Type | Why it exists |
|---|---|---|
| timestamp_utc | Timestamp | Request completion time in UTC. |
| status_code | Int64 | HTTP response status code. |
| environment | Utf8 | Deployment environment. |
Copy the query
WITH hourly AS (
SELECT
date_trunc('hour', timestamp_utc) AS hour,
COUNT(*) AS requests,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS bad_requests
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'production'
GROUP BY date_trunc('hour', timestamp_utc)
)
SELECT
hour,
requests,
bad_requests,
100.0 * bad_requests / NULLIF(requests, 0) AS error_rate_pct,
(1.0 * bad_requests / NULLIF(requests, 0)) / 0.001 AS burn_rate
FROM hourly
ORDER BY hour;This recipe is read-only and reviewed against Telemetry's DataFusion query patterns. Sample output is deterministic and synthetic; validate field types, thresholds, and business definitions against your own data.
Query result
Hourly error-budget burn rate
The 13:00 bucket consumed budget at 3.72 times the sustainable rate.
12:00
0.49×
13:00
3.72×
14:00
1.28×
| hour | requests | bad_requests | error_rate_pct | burn_rate |
|---|---|---|---|---|
| 12:00 | 18,420 | 9 | 0.05 | 0.49 |
| 13:00 | 19,110 | 71 | 0.37 | 3.72 |
| 14:00 | 18,780 | 24 | 0.13 | 1.28 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
How the SQL works
- 1A 99.9% success objective permits a 0.1%, or 0.001, bad-request ratio.
- 2Dividing the observed ratio by 0.001 produces burn rate: 1× is exactly sustainable, while 3× consumes budget three times too quickly.
- 3The CTE keeps the request denominator visible so tiny buckets can be treated separately.
Edge cases to decide
- Define which status codes count as bad for the user-facing SLI; not every 5xx has the same impact.
- Use multi-window alerting for production paging instead of one noisy hourly threshold.
- Exclude synthetic checks or internal traffic only when the SLO definition explicitly excludes them.
Recommended dashboard
- Trend: burn_rate by hour
- Stat: remaining monthly error budget
- Table: routes contributing the most bad requests
Alert guidance
Page only when both a short and long burn-rate window exceed thresholds at meaningful request volume.
Read alert setupPut the recipe to work
Related instrumentation and guides
Continue the analysis
Calculate API Error Rate by Route
Use SQL to rank API routes by 5xx error rate while protecting the result from low-volume noise.
Open recipeCalculate p50, p95, and p99 API Latency
Compare median and tail latency by endpoint with DataFusion-compatible percentile SQL.
Open recipeCompare API Reliability by Release
Compare traffic, 5xx rate, and p95 latency across application releases without attributing every post-deploy change to the deploy.
Open recipeRun 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.