OTLP tracing (export-only)
How Cascades emits traces and metrics — and why there is no REST `/api/traces/{id}` API today.
Model (Option A — export only)
Cascades workers and selected server paths emit OpenTelemetry spans and metrics to an OTLP HTTP endpoint when OTEL_EXPORTER_OTLP_ENDPOINT (and related OTLP env vars) are configured. Traces are pushed to your collector (Grafana Cloud, Honeycomb, Datadog Agent OTLP receiver, etc.); the platform does not host a first-party trace query REST API such as GET /api/traces/{id}.
This keeps the product boundary clear:
- Execution truth lives in Postgres (
workflow_run,task_run,execution_log) and in the dashboard. - Telemetry is a sidecar export path for SREs — not a second persistence layer inside Cascades.
If you need trace inspection
Use your observability backend’s UI (trace search by cascades.workflow_run_id and related span attributes set in workers/workflow-worker.ts and lib/observability/tracing.ts).
Future (Option B)
If product requirements change, a documented GET /api/traces/{id} (or search) surface would be added with Zod schema.ts, OpenAPI fragments, and an explicit decision on authz + retention — it is not implied by OTLP export today.