Skip to content
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 . We checked the SQL syntax, required event fields, sample results, and limits on using the query. Who reviews this page

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 schema

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. We review the synthetic sample output separately. Check field types, thresholds, and counting rules 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
Download this SVG chart of the sample results for an article, runbook, or design review. Please credit Telemetry.

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

  1. 1A 99.9% success objective permits a 0.1%, or 0.001, bad-request ratio.
  2. 2Divide the observed error ratio by 0.001 to get burn rate. At 1×, errors consume budget at the allowed rate. At 3×, they consume it three times as fast.
  3. 3The CTE keeps the request denominator visible so tiny buckets can be treated separately.

Edge cases to check

  • 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

Set up the events this query needs

Related instrumentation and guides

Continue the analysis

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

Get an API key