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.

On this page
  1. Define one impact row
  2. Scope the incident
  3. Verify recovery

Customer Impact Analysis with SQL

An internal error rate does not establish customer impact. Incident response needs a documented product outcome: checkout failed, export delayed, data unavailable, or another controlled effect that a customer could experience.

Define one impact row

Emit or derive one bounded row per incident and approved reporting unit. Useful fields include incident_id, pseudonymous account_id, plan or service tier, controlled impact_type, affected, impact_duration_ms, environment, and UTC time.

Keep the assessed population as well as the affected population. If a join finds only affected accounts, the resulting percentage has no trustworthy denominator. Avoid customer names, emails, request bodies, support messages, and raw content in the aggregate table. Restrict account-level drill-down to approved responders.

Scope the incident

The customer impact SQL recipe counts assessed and affected accounts by plan, calculates the affected share, and averages duration only for affected rows. Its fixture shows three affected enterprise accounts and two affected starter accounts.

Use the query after service-level detection:

  1. Verify the incident start and affected product outcome.
  2. Build the assessed account population for the same complete window.
  3. Compare impact by plan, region, route, or another reviewed bounded dimension.
  4. Track newly affected and recovered accounts as separate flows.
  5. Preserve the query, definition, and result in the incident record.

Do not equate a higher plan with higher human impact without an approved response policy. Plan is one prioritization dimension, not a substitute for contractual or safety requirements.

Verify recovery

Recovery means the customer-visible workflow succeeds again and delayed retries or jobs have drained. A rollback timestamp alone is not proof. Continue watching complete buckets and ensure request volume did not disappear.

The incident response guide covers detection, route and release scoping, timelines, and recovery. The API reliability use case provides the broader event contract that can feed impact analysis.