Telemetry
API reliability SQL recipe

Calculate 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.

Intermediateapi_requestsReviewed 2026-07-27

Question answered

How quickly is the API consuming its 99.9% availability budget?

An error rate becomes operationally useful when it is compared with an explicit reliability objective. Burn rate expresses current bad-request rate as a multiple of the rate the SLO allows.

Event contract

Fields the query expects

FieldTypeWhy it exists
timestamp_utcTimestampRequest completion time in UTC.
status_codeInt64HTTP response status code.
environmentUtf8Deployment environment.
DataFusion SQL

Copy the query

sql
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.

hourrequestsbad_requestserror_rate_pctburn_rate
12:0018,42090.050.49
13:0019,110710.373.72
14:0018,780240.131.28

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

How the SQL works

  1. 1A 99.9% success objective permits a 0.1%, or 0.001, bad-request ratio.
  2. 2Dividing the observed ratio by 0.001 produces burn rate: 1× is exactly sustainable, while 3× consumes budget three times too quickly.
  3. 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 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