Telemetry
Browse docs
Discussion TopicsUpdated July 27, 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. What each signal is good at
  2. Start from the investigation
  3. Where Telemetry fits

Logs, Metrics, Traces, and Structured Events

Observability signals overlap, but they are not interchangeable. Choosing the smallest signal that answers the question keeps instrumentation understandable and cost under control.

What each signal is good at

Text logs preserve detailed diagnostic context for a particular process and time. They are useful for exceptions, unusual branches, and human-readable lifecycle messages.

Metrics summarize a numeric measurement over time. Counters, gauges, and histograms are efficient for service-wide rates, saturation, and latency trends, but they intentionally discard row-level context.

Traces connect spans across a request path. They show which service or dependency consumed time and are valuable when one operation crosses multiple systems.

Structured events describe completed business or application facts as queryable rows. They work well for job outcomes, webhook deliveries, LLM requests, activation milestones, and customer-impacting errors where SQL should group by account, feature, model, route, or release.

Start from the investigation

For “is the service unhealthy?”, a metric and alert may be enough. For “where did this request spend time?”, use a trace. For “what exactly failed in this process?”, inspect logs. For “which accounts encountered failed syncs after the release?”, query structured events.

You can connect signals without copying every attribute everywhere. Put a safe request_id or trace_id on the structured event and diagnostic log. Keep low-cardinality service health in metrics. Store span-specific timing in the trace. This creates paths between systems while preserving the purpose of each.

Where Telemetry fits

Telemetry is designed around structured event tables and SQL. It complements, rather than replaces, infrastructure metrics or distributed tracing. Emit an event at the boundary where a workflow has a useful outcome, then query that table for rates, percentiles, cohorts, and recent examples.

For example, a trace can explain why one checkout took four seconds. A checkout_completed event can show whether version v2 increased p95 latency or payment failures across all customers.

Before adding identifiers, review high-cardinality fields and correlation IDs. For implementation patterns, start with the structured logging guide.