Telemetry
API reliability SQL recipe

Compare API Reliability by Release

Compare traffic, 5xx rate, and p95 latency across application releases without attributing every post-deploy change to the deploy.

Intermediateapi_requestsReviewed 2026-07-27

Question answered

Which releases coincide with worse API errors or tail latency?

Release tags turn a time-correlated incident into a testable comparison. Volume, failures, and latency belong together so a small canary is not judged like a full rollout.

Event contract

Fields the query expects

FieldTypeWhy it exists
timestamp_utcTimestampRequest completion time.
release_versionUtf8Application release or build identifier.
status_codeInt64HTTP response status code.
latency_msFloat64Request duration in milliseconds.
DataFusion SQL

Copy the query

sql
SELECT
  release_version,
  COUNT(*) AS requests,
  100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct,
  approx_percentile_cont(latency_ms, 0.95) AS p95_latency_ms
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '7 days'
  AND release_version IS NOT NULL
GROUP BY release_version
HAVING COUNT(*) >= 100
ORDER BY error_rate_pct DESC, p95_latency_ms DESC;

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

5xx rate by release

Release 2026.07.27.2 has the highest error rate and p95 latency.

release_versionrequestserror_rate_pctp95_latency_ms
2026.07.27.222,6401.821,180
2026.07.27.118,1100.44620
2026.07.26.439,4000.31590

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

How the SQL works

  1. 1Grouping by release keeps overlapping rollout traffic separate.
  2. 2The minimum-volume rule protects the comparison from tiny canary samples.
  3. 3Treat the result as correlation: follow with route, region, customer, and error-type breakdowns before assigning cause.

Edge cases to decide

  • Requests without a release identifier cannot support deploy analysis.
  • A gradual rollout needs deployment start time and traffic share alongside these aggregates.
  • Do not compare releases that served fundamentally different routes or customer segments without segmentation.

Recommended dashboard

  • Bars: error_rate_pct by release
  • Grouped bars: p95 latency and request volume
  • Table: error types for the selected release

Alert guidance

Alert when the newest release exceeds the previous stable release on both rate and minimum 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