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-27Tested with Apache DataFusion 45.2.0

Reviewed by the Telemetry product team on . SQL compatibility, event contract, synthetic output, and operational caveats. Review standards and ownership

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

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.

Hourly error-budget burn rate: static chart of synthetic burn_rate values from the Calculate API Error-Budget Burn Rate example result
Indexable SVG of the deterministic example output. Download it for an article, runbook, or design review with attribution.

Reproduce the example

Download the public fixture

The JSON bundle includes the typed event contract, illustrative input rows, exact SQL, expected output, review notes, and engine version. The CSV contains the displayed result.

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