Telemetry
Browse docs
GuidesUpdated July 28, 2026Reviewed by the Telemetry product team2 min read

Use this doc with your coding agent

Copy a Telemetry prompt and ask Claude Code, Codex, or Cursor to instrument the workflow covered here.

PromptsGet API key
On this page
  1. Instrument the assignment boundary
  2. Compare reliability first
  3. Make rollout decisions reproducible

Feature Rollout Analysis with SQL

A progressive rollout needs a comparison that preserves assignment, release, product outcome, volume, and observation time. Without those fields, a traffic-mix change can look like a feature regression or improvement.

Instrument the assignment boundary

Record the controlled feature-flag name, rollout or control cohort, application release, terminal status, duration, environment, and an approved account or request identifier when needed for deduplication. Keep assignment stable for the comparison window. If an account switches cohorts, preserve the transition time rather than labeling all of its historical events with the latest value.

Do not collect flag payloads, targeting rules, customer attributes, request bodies, or raw error messages. Use a controlled error category and a bounded cohort label.

Compare reliability first

The feature rollout SQL recipe groups requests by flag, cohort, and release. It keeps request count, failed count, error rate, and average latency together. The deterministic fixture shows a rollout cohort with one failure and slower average latency while its control cohort has no failures.

Review the result in order:

  1. Confirm that both cohorts observed the same release and complete time window.
  2. Require enough requests in control and rollout.
  3. Compare error rate and latency, then inspect controlled error categories.
  4. Segment by plan, route, or region only when allocation and volume support it.
  5. Pause, continue, or expand using a written guardrail.

For business outcomes, join the same stable assignment to an activation or revenue milestone only after reliability is acceptable. The product journey guide shows how to keep the counting unit explicit.

Make rollout decisions reproducible

Save the SQL, lookback window, minimum sample rule, release, and rollout percentage with the decision. Dashboards should mark allocation changes and deployments so responders can distinguish a feature effect from a simultaneous code change.

Use API reliability recipes for error budgets, release comparisons, customer impact, and dependency latency. A guardrail should require sustained evidence; one low-volume failure should trigger review, not an automatic irreversible conclusion.