Telemetry
Telemetry SQL Cookbook

Learn SQL across one connected SaaS telemetry database

Follow an account from signup to activation, model usage, background work, billing, and customer-impacting API failures. Every lesson runs locally against the same synthetic tables, so joins and business definitions stay visible.

Reviewed by the Telemetry product team on . Synthetic data contract, join grain, read-only SQL, expected results, and interpretation boundaries. Editorial ownership

Start the first lessonDownload dataset

6

connected tables

60

deterministic synthetic rows

5

guided SQL lessons

Dataset contract

Six tables, one deliberate join key

The synthetic account_id connects commercial context to product, reliability, AI, job, and billing outcomes. More specific identifiers preserve the grain inside each workflow. No customer records, prompts, payloads, or credentials are included.

accounts6 rows

One synthetic SaaS account with the dimensions and recurring revenue needed for customer-impact analysis.

One row per account.

account_id
View 5 fields
account_id Utf8
Stable synthetic account identifier.
plan Utf8
Commercial plan at the end of the sample window.
region Utf8
Coarse hosting or customer region.
signup_at Timestamp
When the account entered the sample cohort.
monthly_revenue_usd Float64
Synthetic normalized monthly recurring revenue.
product_events21 rows

Durable account and user milestones for activation, adoption, and journey analysis.

One completed product milestone.

account_iduser_idsession_id
View 9 fields
timestamp_utc Timestamp
When the milestone completed.
event_id Utf8
Stable identifier for deduplication.
account_id Utf8
Joins the event to the synthetic account.
user_id Utf8
Synthetic actor identifier.
session_id Utf8
Groups ordered events within a visit.
event_name Utf8
Stable product milestone name.
feature Utf8
Product surface responsible for the event.
status Utf8
Final milestone outcome.
release Utf8
Application release that produced the event.
api_requests10 rows

Completed API request events with stable route, release, latency, and customer context.

One completed API request.

account_idrequest_id
View 7 fields
timestamp_utc Timestamp
When the request completed.
request_id Utf8
Stable request correlation identifier.
account_id Utf8
Joins the request to the synthetic account.
route_template Utf8
Bounded route shape without raw identifiers.
status_code Int64
Final HTTP response status.
latency_ms Float64
End-to-end request duration.
release Utf8
Application release serving the request.
llm_requests11 rows

Normalized provider usage, estimated cost, retry, and reviewed product-outcome fields.

One completed model request, including provider retries as separate rows.

account_idrequest_id
View 12 fields
timestamp_utc Timestamp
When the provider request completed.
request_id Utf8
Stable model request identifier.
account_id Utf8
Joins model usage to the synthetic account.
feature Utf8
Product workflow using the model.
provider Utf8
Normalized model provider.
model Utf8
Provider model identifier captured at request time.
input_tokens Int64
Provider-reported input-token count.
output_tokens Int64
Provider-reported output-token count.
estimated_cost_usd Float64
Estimated request cost under a versioned pricing rule.
status Utf8
Final provider request outcome.
retry_count Int64
Automatic provider retry count for this logical operation.
accepted Boolean
Whether the user accepted or saved the resulting output.
job_runs7 rows

Attempt-level background-job outcomes with queue and execution timing.

One attempt of a logical background job.

account_idjob_id
View 9 fields
timestamp_utc Timestamp
When the attempt reached a terminal outcome.
job_id Utf8
Logical job identifier shared by retries.
account_id Utf8
Joins job impact to the synthetic account.
job_name Utf8
Bounded worker operation name.
status Utf8
Attempt outcome.
attempt Int64
One-indexed attempt number.
queue_wait_ms Float64
Time waiting before execution.
duration_ms Float64
Worker execution time.
error_type Utf8
Controlled failure category or null on success.
billing_events5 rows

Synthetic subscription outcomes for connecting product behavior and reliability to commercial context.

One completed billing lifecycle event.

account_idevent_id
View 6 fields
timestamp_utc Timestamp
When the billing event completed.
event_id Utf8
Stable provider-event identifier.
account_id Utf8
Joins the event to the synthetic account.
event_name Utf8
Normalized billing lifecycle outcome.
amount_usd Float64
Synthetic normalized amount.
status Utf8
Final billing-event outcome.

Reduce before joining

Collapse requests, attempts, or milestones to the business grain before adding account and revenue context.

Synthetic by construction

The dataset is deterministic, versioned, and intentionally small. It demonstrates logic rather than customer benchmarks.

Interpretation is part of the lesson

Every query names the denominator, business decisions, and claims the result cannot support.

FoundationsBeginner

Summarize daily product activity

Which milestones are users completing on each day?

Start with one event table, group durable product milestones into UTC days, and keep successful volume separate from all attempts.

The dataset and query remain in this browser.

Published expected result

Daily successful product milestones

activity_dayeventssuccessful_eventsactive_accounts
2026-07-01221
2026-07-02442
2026-07-03322
2026-07-04441
2026-07-05332
2026-07-06221
2026-07-08111
2026-07-09111
2026-07-12111

How to read the query

  • The UTC day is derived from the event timestamp instead of a client-supplied date label.
  • Event volume and distinct active accounts answer different questions, so both remain visible.
  • The status condition prevents a failed integration attempt from being counted as a completed milestone.

Decisions the SQL cannot make

  1. 1Decide whether retries and repeated milestones should remain visible.
  2. 2Exclude internal, test, or bot accounts before treating this as adoption.
  3. 3Use complete time buckets when comparing recent days.

Continue from this lesson

SQL time bucketingConditional aggregation

Move from the lab to your own event contract

Keep the analysis grain and join logic, then replace the synthetic tables with your own stable event names and privacy-approved identifiers. Validate thresholds and commercial definitions with the team that owns them before promoting a query to a dashboard or alert.

Testing methodologyEvent schema guideUse your own events